[Distutils] formencode as .egg in Debian ??

Chad Walstrom chewie at wookimus.net
Tue Nov 29 08:02:12 CET 2005

Josselin Mouette <joss at Debian.org>  wrote:
> Creating debs easily is a good idea if done correctly, but only for
> packages that will eventually enter the archive. It's a very bad
> idea to encourage people to build their own versions of Debian
> packages. It would lead to a horrible cluttering of package sources,
> and to the disappearance of any coherent versioning scheme.

As a fellow Debian Developer, I say, "Hogwash!"  If Debian isn't
providing *.deb's, then there's nothing wrong with upstream providing
their own, regardless of vaporish eventualities.  In fact, it's
presumptuous to assume that Debian has *any* control over upstream's
practices.  I applaud Phillip for his assistance in trying to resolve
the issue at hand.

I for one encourage upstream to provide packages in any and all
formats that they're willing to.  All the better if the package is
policy compliant, has sane dependences, and compiled against latest
stable and unstable archives, but these are by no means a requirement.

Given that Debian developers are volunteers and may not be as
responsive to user's bug reports as upstream may be, the centralized
nature of Debian you tout as being so grand isn't always so.  I admit
freely that had I more time, I might be able to respond more quickly
to bug reports and feature requests. (Not to mention the politics and
overly-strict, glacial policies.)

So, I again encourage software developers to provide packages to any
system they might want to support, and if they need help with
packaging software for official inclusion to Debian, there are plenty
of developers and new maintainer candidates willing to help.

> However, if a semi-automated way to produce Debian source packages
> is available, like it is for CPAN modules, it can only be a good
> thing, as it will be used to make loads of packages that can enter
> the archive.  And there's no reason why all these python modules
> couldn't enter the archive.


> ...You seem to forget your software isn't the only one out there;

Presumptuous, shortsighted troll, and totally uncalled for.  In fact,
I believe Phillip, et. al. have been arguing the exact opposite.
Folks, we don't all act this way.

> we are providing a centralized way to get feedback, redistributing
> it when necessary. This makes things much easier for users when they
> have only one way to give feedback.

...which can have response problems proportional to the time
investment of the developer maintaining the package.

> ...You're going to use the features as soon as they are available in
> the release. And releases are available in Debian unstable.

s/are/may be/

Of course, that is if we can come to some sort of technical agreement

> You're mixing things again, and again, and again. Debian
> dependencies should NOT be mixed with lower-level dependencies.

It depends (no pun intended -- O.K. maybe a little), and you state so
in your next sentence.

> A clean way of doing things would be a shlibs-like mechanism.

For those unfamiliar with such terminology, shlibs is a debhelper
script that heuristicly resolves dependencies found at package build
time and then updates the appropriate field in the binary package(s)
built for the source.  In fact, I believe this has been suggested a
number of times in this thread already.

> However, it would require dependencies to be written only in
> metadata files. As I understand it, they can also be asked directly
> in python code, in which case there's no reliable way to tell a
> package needs another package.

Yet there's no reason to exclude the possibility of creating a
Debian-specific hook in for easy_setup/setup.py to resolve these
introspectively as well.  Regardless, it's up to the packager to add
appropriate package dependencies that cannot be resolved by automated
scripts.  This is not a new issue or one isolated to eggs.

> That can be done in the unstable package. However, you're still
> going to get complaints from sarge users because your software won't
> see the stable ElementTree package. The same goes for RHEL4 users.

Not an issue.  Sarge (stable) users can get backports of all their
favorite bleeding-edge software like they always could through
upstream developers who package their own *.debs or through interested
Debian developers who upload to sites such as http://backports.org.

Chad Walstrom <chewie at wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

More information about the Distutils-SIG mailing list