[Pkg-mono-devel] libanculus-sharp review

[David Paleino]

On Sun, 15 Jun 2008 21:43:42 +0200, Mirco Bauer wrote:

> On Sun, 2008-06-15 at 21:20 +0200, David Paleino wrote:
> > > And where is the monodoc documentation package? Without it you are
> > > pretty clueless when developing an application using that library. As
> > > example check the webkit-sharp source package (its in pkg-cli-lib SVN
> > > repo).
> > 
> > Yes, I saw it.
> > I didn't add it just because I didn't know I would have to. The CLI Policy
> > is apparently missing this point :(.
> > I'll see webkit-sharp and act consequently, thanks.
> 
> Well, I don't see the point that a packaging policy would require to
> have documentation in a package. It's just that upstream in this case
> ships already documentation for monodoc in their tarball, so removing it
> on purpose doesn't seem to be the best thing to do.

I didn't think I was removing anything on purpose :(.
I just missed the docs, sorry :s. I'll work on this, I promise :-p

> > > > +On Debian systems, the complete text of the GNU General
> > > > +Public License v2 can be found in `/usr/share/common-licenses/GPL-2'.
> > > 
> > > Inconsistency here, above it says GPL-2+ (notice the +), while this
> > > reference is for v2 only.
> > 
> > Uhm... another DD (for other packages) told me that if I use "GPL-2+", I
> > should point to ./GPL (which is GPL-3) -- is that right?
> 
> Ok, I added some confusion here, I thought GPL-2 says "2 only" but I
> just checked and its 2+, so your reference to GPL-2 was correct.
> 
> >  I'm willing to use GPL-3+,
> > but can't really say if it's MIT-compatible (truly, I didn't check this at
> > all).
> 
> MIT is compatible to everything as there aren't really restrictions
> (BSD-style license).
> 
> > However, this has been fixed (rev3774)
> 
> Feel free to revert that to GPL-2 if you prefere GPL2+ licensing, thats
> your decision :)

GPL-3+ then :)

> > > > +/usr/lib/libanculus-sharp/Anculus.Core.dll
> > > > +/usr/lib/libanculus-sharp/Anculus.Core.Extended.dll
> > > > 
> > > 
> > > Wrong location, check 3.1.2 of the CLI policy.
> > 
> > Fixed this with a patch to *.pc.in files, and a quick hack in debian/rules
> > (rev3775)
> 
> The new locations:
> -/usr/lib/libanculus-sharp/Anculus.Gui.dll
> -/usr/lib/libanculus-sharp/Anculus.Core.dll
> -/usr/lib/libanculus-sharp/Anculus.Core.Extended.dll
> +/usr/lib/cli/libanculus-sharp/Anculus.Gui.dll
> +/usr/lib/cli/libanculus-sharp/Anculus.Core.dll
> +/usr/lib/cli/libanculus-sharp/Anculus.Core.Extended.dll
> 
> are still incorrect though. First it should use the "upstream package
> name" which seems to be anculus-sharp or just anculus (as the
> pkg-config files are called anculus-*.pc)

The upstream name is "libanculus-sharp" -- at least that's what the tarball is
named, and what the subdirectory in /usr/lib is named by upstream's Makefiles
and autotools.
I'm willing to change that to "anculus-sharp" (as gnome-sharp, gtk-sharp,
gecko-sharp, webkit-sharp and so on), but is this TheRightThing™ to do?

> and the ABI version is missing in the directory name too. That's very
> important when an ABI breakage happens, that both versions are installable at
> the same time (thus they must use different locations).

Do you mean something like "anculus-sharp-0.3/" ?

> > > The debian/rules file would be much shorter and thus simpler and easier
> > > to maintain, if you use dh7 minimalistic style packaging, as example
> > > take a look at webkit-sharp.
> > 
> > I've never used that style, but I've also read the original post about it by
> > Joey (probably him, but I may be wrong) on -devel (?). I don't really like
> > "blackbox" solutions (i.e. where you don't see what is being done, like
> > cdbs is IMHO),
> 
> I agree, I don't like blackboxes either, and yes CDBS is such beast.
> 
> debhelper uses a different approach though. The main control flow is
> still 100% in your debian/rules file, its just that it calls a list of
> common dh_* commands automatically for you. I added support that it even
> calls all needed dh_*cli* commands automatically in the right order.
> 
> (while cdbs moves the main flow into CDBS and you only get some CDBS
> hooks to do something and maybe the right hook that you need exists :))

ACK :)


> >  and at a quick look on what you've done with webkit-sharp, it seems so
> > to me. But, I admit, I haven't looked at it with attention (nor I have done
> > `man dh`, which seems to be necessary, since it's used throughout the
> > Makefile). If it's not a problem, I prefer to keep it like it is.
> 
> I only suggested to switch to dh7-style, if you feel more comfortible
> with the conventional debhelper way no problem :)

As already said, I'll study dh7 -- I've got some packages with ugly
debian/rules, and I'd like to make them easier (independently from
pkg-{mono,cli-*})

Thanks,
David
(who still waits to be approved in mailing lists subscriptions... if you can,
please also add me to respective -commits :) )

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-mono-devel/attachments/20080616/e6a5a3a4/attachment.pgp