On Sun, Sep 29, 2002 at 05:51:30PM +0200, Bastian Kleineidam wrote: > On Sun, Sep 29, 2002 at 11:29:02PM +1000, Donovan Baarda wrote: > > I've just had a look at this and it looks good. It perfectly meets the > > requirement of allowing pure python module packages to support multiple > > pythonX.Y python packages simultaniously. > > > > The only problem is we are still missing something. We still can't easily > > support pure python _program_ packages that work with multiple versions of > > (the default) python. > What is wrong with > Depends: python2.2 | python2.3, python (>= 2.2), python (<< 2.4) > This supports the 2.2 and upcoming 2.3 default python package.
Yes it does. However, under python central this means you would have all the modules compiled and symlinked for both python2.2 and python2.3 if they were both installed. This is great if you want to use these modules from both pythonX.Y versions, but in the case of something like mailman, you only want to use them from the default python. Having the other pythonX.Y support is not required. > > Programs like mailman put their modules in their own /usr/lib/mailman > > directory. One way that mailman _could_ support multiple pythonX.Y packages > > it to have the packager move _all_ the modules into a > > /usr/lib/python/site-packages directory and then use python central. > > However, this is overkill for mailman because it doesn't need to support > > python2.1 and python2.2 simultanously, just the default python. It is also > > hell for the packager. > 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. > 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. > > Another thing I noticed, the man pages are now recommending using; > > > > Depends: python (>=2.1) > > Conflicts: python (>= 2.4) > > > > Doesn't the policy have; > > > > Depends: python (>=2.1), python (<<2.4) > > > > I think these mean the same thing, but has the policy changed for some > > reason? I actually think that "Conflicts" is less ambiguous... > > 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. > > Pending feedback/ideas whatever, I can code something up to do this. I > > probably favor using python-apt (if it can actualy do it) or grep-dctrl to > > do the package lookup stuff, but can do it manually if this is a problem. > Dont code anything like that. I'd rather fix those hacky'ish packages > which try to append something to sys.path. I think this needs feedback from the people actually maintaining the packages. If they think restructuring into /var/lib/python/site-packages is a good idea, then fine. However, if they would prefer to structure their files the same as upstream does... -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------
