[Distutils] formencode as .egg in Debian ??

[Josselin Mouette]

Le dimanche 27 novembre 2005 à 16:26 -0600, Ian Bicking a écrit :
> >>No one is forcing Debian to package any of these.  
> > 
> > Of course you are forcing Debian to package these. As long as your
> > projects have enough users, someone will want to build a Debian package.
> > The whole point of this thread is to make this package not suck.
> 
> easy_install works, right now, for these packages.  There are some
> outstanding issues, and those issues can probably be resolved in
> easy_install, without any intervention by Debian.  Maybe the simplest
> resolution is adding an option like:
> 
>   easy_install --already-provided=1.2.6 ElementTree

We're not going to tell our users to use easy_install for some kind of
packages and some other thing for another package, and so on. They
expect to be able to install anything, just by typing "apt-get install
foo".

> that will create a .egg-info directory.  And we can encourage people to
> fix Debian by putting a distutils.cfg file in place that installs
> distutil software in /usr/local by default, as opposed to the current
> situation where I believe distutils installs go alongside Debian packages.

This is an entirely different matter, which indeed deserves a bug report
if it isn't done already.

> > I'm happy you see stable releases as "counterproductive". However many
> > of our users happen to like them, as they don't like to upgrade their
> > software every other day. Again, eggs are a useful tool only for
> > developers, not for regular users.
> 
> These are developer tools, regular users *are* developers.
> 
> If someone reports a bug, and I fix it, and they can't get access to
> that because they can't install a new version of the package, then that
> is counterproductive.  It discourages feedback.

Stable releases are not meant for developers like you, but there are
developers who want a stable development platform, even if it has some
bugs. No bug fixing also means no regressions. The fact you don't
understand those people's needs - and forget them when designing your
tools - doesn't make all stable releases "counterproductive".

Developers who want a bleeding edge development platform should be using
Debian testing or unstable, where the new versions become available as
soon as possible.

> > I fail to see how it changes anything. If it's to be able to install two
> > versions of the same package at once, I have already explained why it's
> > a bad idea to even support it.
> 
> Then you are cutting off me, the upstream maintainer, from the users,
> because everything has to go through the Debian packager, and a separate
> release cycle.

Yes. Bugs in the Debian package should go to the Debian packager. 

> *Or*, we develop various ad hoc techniques to allow
> people to install other versions of packages *in spite* of the Debian
> packages.

If your packages can't be installed in /usr/local, where they take
precedence over the version in /usr, your packaging system is flawed.

> I just don't think it is an option to say that only one version of a
> package can be installed.  In /usr/lib/pythonX.Y/site-packages, sure,
> and there can potentially be other restrictions.  But you are limiting
> your users too much if there can never be multiple versions installed.

Stable users will want to keep the same version, and allowing them to
install several versions provides a way to easily break their systems.
It also cuts them off the security fixes.

Testing/unstable users have the new packages as soon as possible, and
the new package should replace the old one entirely.

> > It should be obvious Debian packages aren't useful for the development
> > of the packages themselves. They are a way to install software in an
> > easy and generic way for our users. If your software isn't useful to
> > anyone else than the people developing it, it should indeed not be
> > packaged for Debian.
> 
> This is where the whole thing becomes weird, IMHO.  I'm a Debian user
> (among several distributions).  I'm also a developer.  As such, the
> Debian system doesn't work well for me.  The system doesn't need to be
> primarily targetted at my use case, but I think my use case at least
> needs to be taken into account.  Much of the software we are currently
> talking about is primarily targeted at people like myself (the exception
> would be Trac, though even that has a developer focus).  This may change
> at some point -- there might be useful applications that Debian users
> want easy access to, and those applications in turn require one of these
> libraries.

I think you are missing my point. When I'm developing software, I can
use Debian for that. However I won't rely on the Debian packages of my
own software, this simply makes no sense.

Now, if you are developing software based on some python modules, if
these modules are packaged in Debian, it's perfectly possible, as long
as you're not going to hack the modules themselves. And when it's
packaged in Debian, you don't need egg-style dependencies, as Debian
dependencies already take care of it.

Regards,
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette at ens-lyon.org
`. `'                        joss at debian.org
   `-  Debian GNU/Linux -- The power of freedom