Re: Upstream debian/ directory
I'm all for it; I do this with all my projects, actually.
One suggestion I got was to name your directory deb/, and have your
configure script make a link from debian to that (unless a debian directory
exists). This is because if your package ever becomes official, there is a
chance that you will not the Debian maintainer for it, and the real
maintainer might want/need different Debian information. Thus, they can
easily add their own debian/ directory.
Also, in your control file, make the description and summary clearly state
that the package is "unofficial." That way you will (slightly) decrease the
likelihood of clueless idiots bugging Debian maintainers for bugs in your
software.
> Hi! I wanted to start a thread about whether or not having at least a
> minimal debian packaging system in the upstream of a piece of software
> is a good thing, a bad thing, or harmless.
>
> --------------------------------------------
> Here are my arguments for it:
>
> Users may want the package for a frozen distribution (say potato). You
> can't retroactively put it in potato. However, to assist these users,
> having packing information upstream allows them to build a package with
> minimal know-how.
>
> Putting up an alternative apt source is of course one option, but in
> this way it's all together; the user doesn't have to go hunting. Also,
> it's a more credible source than some back-alley url run by a
> shifty-eyed dude who *claims* he's a debian-developer. ;-) In fact, the
> prebuilt debs (for potato) could be on the upstream site.
>
> Presently, RPMs work this way---many packages include the .spec file
> with the tar.gz and include prebuilt rpms for several platforms.
>
> Further, it demonstrates that the upstream authors agree with where the
> files in their package are ending up on an installed system. This is a
> good thing esp. since future packaging for other distros will then use
> the same locations. How much of a pain in the ass is it that db3 lands
> in
> /usr/local/BerkleyDB3.2/[include|lib] and half a dozen other places on
> different architectures?
>
> For packages that do not use automake/etc and for some reason do not
> have install rules, the location of installation is thus made explicit.
>
> In cases where a package cannot be put in debian (mplayer) the
> packaging information has to go somewhere.
>
> Tighter coupling of packaging information and the upstream helps the
> upstream authors think more about people who use their software. If
> developers of a library had to think about how they would find their
> library portably and/or where it should go, how to get the soname
> right, etc. Maybe configure scripts wouldn't have to be such a bitch!
>
> --------------------------------------------
> Here are my arguments against it:
>
> Still requires debian-specific patches between upstream releases to fix
> packaging errors. This ends up with out-of-sync packaging information.
>
> RPMs only have .spec files upstream b/c there is no centralized
> repository for RPMs so the authors have to assume the burden.
>
> For users who need it for potato, apt-get source -twoody foo; cd foo;
> debuild works as well as just downloading it from the upstream.
>
> --------------------------------------------
>
> Obviously, I'm not advocating this for all packages. However, in some
> cases I think this makes sense. Especially if the debian developer
> works very closely with the upstream developer.
>
> What are other peoples thoughts on this?
> Thanks.
>
> --
> Wesley W. Terpstra <wesley@terpstra.ca>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
Reply to: