[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Upstream debian/ directory



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>



Reply to: