On Thu, Oct 03, 2002 at 05:21:34PM +0200, Matthias Klose wrote:
> Donovan Baarda writes:
> > > I wouldn't call moving some files the packaging hell, and I have yet to
> > > understand why /usr/lib/mailman is so much saner or better than
> > > /usr/lib/python/site-packages/mailman.
> > > I looked into the mailman package. It should not be that much work to
> > > adapt it to the python-central framework (moving the Mailman module
> > > into .../site-packages/, removing the paths.py hack).
> > > And when the mailman Bug#162761 is fixed, I could even provide a patch ;)
> >
> > I guess this is an issue of "upstream compatiblity". Sure, packages could be
> > restructured to fit the scheme, but the other alternative is to masssage the
> > scheme to fit the upstream packages...
> >
> > I think that using /usr/lib/python/site-packages/mailman properly is the
> > _right_ way to do it, but I can see the argument for /usr/lib/mailman,
> > particularly when upstream does it that way.
>
> IMO this is absolutely wrong.
I was agreeing with you :-)
The reason I said site-packages is the _right_ way, is it makes mailman
modules usable from other applications. However, I agree that we shouldn't
_require_ application specific modules to be in site-packages, particularly
when upstream don't package that way. As you pointed out there are plenty of
good reasons not to put stuff in site-packages.
[...]
> So python-central _has_ to handle the case of python files laying
> around somewhere (i.e. /usr/lib/foo/{bar,baz}.py), recompiling these
> files on python upgrades.
>
> Please design python-central for all kind of packages, do not require
> the packages to be adapted to python-central.
That's another vote for support of python application packages with modules
outside /usr/lib/python/site-packages :-)
> > > Conclusion: the python-central framework as it is now offers enough for
> > > everyone. If people don't want to use it, they are on their own.
> >
> > I think we could add support for the mailman case with minimal hassles...
> >
> > The biggest problem I can forsee is this introduces another option that will
> > confuse developers... But this can be rectified with "strongly suggests" in
> > the python policy.
>
> There should be no confusion telling python-central the locations of
> files to be registered.
The confusion I was refering to was the "is a python-foo package
optional/encoraged/required for my pythonX.Y-foo packages" type questions
that have cropped up in responce to the current policy. I think this option
will raise "should I put my modules in /usr/lib/foo or
/usr/lib/python/site-packages/foo" type questions unless we clarify the
circumstances for each in the policy.
Is there any cases you can think of where 'dpkg -L <python-foo> | grep *.py'
will not be sufficient to identify the files to be "registered"?
> > > Hmm, reading the Debian policy, the only difference is that Depends only
> > > are considered on configuring a package, Conflicts are considered on
> > > installing. I dont know whats better, I think either will do.
> > > I will adapt the man pages to the Python Policy.
> >
> > Give this, I would prefer the "Depends" rather than "Conflicts", as it more
> > closely matches what a python version incompatability means... you can
> > install the files, but you can't configure them to work.
>
> please send a patch for the policy.
The "Depends" option is what is in the current policy. The python-central
man page was not matching the current policy.
> Bastian Kleineidam writes:
> > python-central (0.4) unstable; urgency=low
> >
> > * renamed register-python-package to python-register, this way
> > its prefixed with "python" (and its shorter ;)
>
> as long as python-central handles libraries/modules only, it should be
> called register-python-library. Don't confuse the packager ;-)
It'll get there eventualy :-)
--
----------------------------------------------------------------------
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
----------------------------------------------------------------------
