From symbiont at berlios.de Mon Dec 20 07:56:41 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon Dec 20 08:00:00 2004 Subject: [PyVault-devel] Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <20041219120158.GG21371@neu.nirvana> References: <20041215115237.GA22486@neu.nirvana> <200412161024.43213.symbiont@berlios.de> <20041219120158.GG21371@neu.nirvana> Message-ID: <200412201456.41861.symbiont@berlios.de> Axel: Taking this to repo-coord, since there are several Python packagers that potentially want to comment on these issues. Hope that's okay. All: Normally, I'd thread my responses with the email that was sent, but it's a little unwieldy and I hope all can get the context with which this discussion was started with. I'll include the original piece for context. Anyway, the request was given that an RPM named "python" be provided that does some housekeeping and symlinks without using alternatives in the version-specific pythons (python23, python24). However, there is a weakness in RPM where it will automagically Obsoletes previous versions of Python when executing an Upgrade. I've tried this 1 billion ways already and it doesn't work. In addition, there are /usr/bin/* programs supplied with libs like PyXML that could be alternative'd, but the current version inside of chkconfig that comes Redhat cannot handle dealing with alternatives spanning across a set of packages. Earlier in the year, I've sent a draft Nomenclature document which I have updated with your ideas and tried my best to implement all of your input into this repo. But there are a lot of limitations that we need to work around while trying to obtain the ultimate goal of the repository of itself. This is stated in the document. Please see the updated document here: http://www.python.org/pyvault/naming.html The scope of the document is expanding, so in the near future I'll probably rename it to the Pyvault Python Policy to reduce confusion. But, the gist of it is to make available a set of packages that maintains compatibility with existing python packages without impacting those that Pyvault does not maintain (system-config-* and friends). I'd like to use natural names where possible, but the RPM issue with Obsoletes still lurks. Providing unique package names with the versioned Python inside of it is the only way to prevent this. On a side note, Debian folks have already hashed back in forth about Python policies ahile ago. Looks like we're behind the times. ;-) http://lists.debian.org/debian-python/2001/09/msg00086.html http://lists.debian.org/debian-python/2001/09/msg00090.html They're workarounds were different than the ones we need, but nonetheless useful to learn from. Open items that need to be resolved: * Do we really %ghost *.pyo? That's what I'm doing now as an experiment discussed over at fedora.us. I'm not sure if Extras will have this policy or not. * Need to re-bytecompile applications for the latest version of python. (see http://www.fifi.org/doc/mailman/README.Debian) * I'm certain there's more ... :) take care, jeff On Sunday 19 December 2004 20:01, Axel Thimm wrote: > I've been doing some thinking around this. How about the following > scheme, which is almost already what pyvault does: > > python15 > [...] > python22 > python23 > python24 > > are packages that don't conflict/overlap and also have no > alternatives/symlinks etc. Using python means calling it as python2.4 > etc. > > All python module/app packages built should get their > "#! /usr/bin/python" replaced with the matching python version they > were built against. So every python package pulls in the right > pythonXX package and uses it independently of /usr/bin/python > settings. > > And then there are "python" packages that just setup the symlinks in > bin for the vendor and user (e.g. python on RH7.3 still points at 1.5 > for compatibility's sake. These packages are not really needed for > pyvault package to work. > > python-devel package should always point to the latest available > python in pyvault. That ensures that you can always use > "BuildRequires: python-devel >= ..." w/o using any numbered python > (=> no specfile editing when rebuilding other than tags). For > packages (build)requiring an older python the explicit pythonXX-devel > tags can be used to lock it onto a python version. > > On the python module/app package versioning: I'd skip the python > version built against (just like perl and C do not include the perl > or glibc version against their were built) and use natural names. > After all when pyvault supports a new python on all distributions, > all package will be built against it, and the few that need fixing > will just depend on a slightly older python. > > I.e. the use model assumes that the pyvault maintainer and > packager(s) test a new python version, approve it for becoming the > next base version and rebuild everything against it. pyvault also > provides the compatibility packages for other python packages not > included in pyvault (like the vendor's), and also some python > packages that won't build against the latest approved python version. > > It is also more maintainer friendly (i.e. don't support package pyfoo > on multiple different python version, only one one). > > Does that model sound OK for you? -- -jeff From symbiont at berlios.de Mon Dec 20 08:02:56 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon Dec 20 08:06:17 2004 Subject: [PyVault-devel] Re: [repo-coord] Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <200412201456.41861.symbiont@berlios.de> References: <20041215115237.GA22486@neu.nirvana> <20041219120158.GG21371@neu.nirvana> <200412201456.41861.symbiont@berlios.de> Message-ID: <200412201502.56735.symbiont@berlios.de> On Monday 20 December 2004 14:56, Jeff Pitman wrote: > On a side note, Debian folks have already hashed back in forth about > Python policies ahile ago. ?Looks like we're behind the times. ;-) > > http://lists.debian.org/debian-python/2001/09/msg00086.html > http://lists.debian.org/debian-python/2001/09/msg00090.html > > They're workarounds were different than the ones we need, but > nonetheless useful to learn from. FYI -- Latest Debian Python Policy I found: http://da2i.univ-lille1.fr/cgi-bin/dwww?type=file&location=/usr/share/doc/python/python-policy.html/ch-python.html -- -jeff From symbiont at berlios.de Mon Dec 20 16:53:12 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon Dec 20 16:56:30 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <20041220111304.GD20677@neu.nirvana> References: <20041215115237.GA22486@neu.nirvana> <200412201456.41861.symbiont@berlios.de> <20041220111304.GD20677@neu.nirvana> Message-ID: <200412202353.12341.symbiont@berlios.de> On Monday 20 December 2004 19:13, Axel Thimm wrote: > > However, there is a weakness in RPM where it will automagically > > Obsoletes previous versions of Python when executing an Upgrade. > > Which obsoletes are you thinking of? Are any really needed (other > than replacing the vendor python with the pythonXX packages)? Ahhh! The *invisible* obsoletes, of course!! http://distro2.conectiva.com.br/pipermail/apt-rpm/2004-August/002513.html http://lists.atrpms.net/pipermail/repo-coord/2004-August/000357.html I mean, I like your idea. It maps closer to Debian Python Policy, etc. But, we cannot do it. I've tried with sweat and blood. It only brings frustration when the Package itself (python) automatically removes *any* and *all* packages that Provides: python = x.y.z, even if they're named foobaz2.2, when python=2.3.4 is upgraded ... *boom*. It's hard to believe ... so, take Paul's provider.spec and give it a shot: http://people.redhat.com/pnasrat/provider.spec > > But, the gist of it is to make available a set of packages that > > maintains compatibility with existing python packages without > > impacting those that Pyvault does not maintain (system-config-* and > > friends). > > That's perhaps unavoidable. If a pyvault user wants to have > /usr/bin/python point to python 2.4 for his own pleasure and > system-config-* and friends break with it, the you either need to > educate users to use /usr/bin/python2.4 or [...] I'd rather choose between educating users via FAQ or build a "python" wrapper that flipped between versions. I'd rather not repackage the whole nine yards. > > I'd like to use natural names where possible, but the RPM issue > > with Obsoletes still lurks. ?Providing unique package names with > > the versioned Python inside of it is the only way to prevent this. > > I still don't see where the obsoletes enter. You mean python module > packages, not the python packages, right? Why should python module > ackages obsolete something? See above. The names are just pythonXY and pythonXY-module for this reason and for the sake of consistency. > > * Do we really %ghost *.pyo? ?That's what I'm doing now as an > > experiment discussed over at fedora.us. ?I'm not sure if Extras > > will have this policy or not. > > * Need to re-bytecompile applications for the latest version of > > python. (see http://www.fifi.org/doc/mailman/README.Debian) > > Isn't this only an issue when installing into non-versioned python > dirs, which one should not do? :) Well, if one does not package .pyo, they'll possibly get created if a root user runs an application with -O as the flag. Whether executed from the commandline or whether #!/usr/bin/python -O. So, in order for a clean exit on a particular python, you'd want to make sure everything is gutted by using %ghost. The reason they're not there is because the intrinsic value of their existence versus the space consumption doesn't match up. YMMV--just a blind experiment, I guess. This piece has a good summary: https://www.redhat.com/archives/fedora-devel-list/2004-August/msg00249.html take care, -- -jeff From Axel.Thimm at atrpms.net Mon Dec 20 12:13:04 2004 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Mon Dec 20 17:08:27 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <200412201456.41861.symbiont@berlios.de> References: <20041215115237.GA22486@neu.nirvana> <200412161024.43213.symbiont@berlios.de> <20041219120158.GG21371@neu.nirvana> <200412201456.41861.symbiont@berlios.de> Message-ID: <20041220111304.GD20677@neu.nirvana> On Mon, Dec 20, 2004 at 02:56:41PM +0800, Jeff Pitman wrote: > On Sunday 19 December 2004 20:01, Axel Thimm wrote: > > I've been doing some thinking around this. How about the following > > scheme, which is almost already what pyvault does: > > > > python15 > > [...] > > python22 > > python23 > > python24 > > > > are packages that don't conflict/overlap and also have no > > alternatives/symlinks etc. Using python means calling it as python2.4 > > etc. > > > > All python module/app packages built should get their > > "#! /usr/bin/python" replaced with the matching python version they > > were built against. So every python package pulls in the right > > pythonXX package and uses it independently of /usr/bin/python > > settings. > > > > And then there are "python" packages that just setup the symlinks in > > bin for the vendor and user (e.g. python on RH7.3 still points at 1.5 > > for compatibility's sake. These packages are not really needed for > > pyvault package to work. > > > > python-devel package should always point to the latest available > > python in pyvault. That ensures that you can always use > > "BuildRequires: python-devel >= ..." w/o using any numbered python > > (=> no specfile editing when rebuilding other than tags). For > > packages (build)requiring an older python the explicit pythonXX-devel > > tags can be used to lock it onto a python version. > > > > On the python module/app package versioning: I'd skip the python > > version built against (just like perl and C do not include the perl > > or glibc version against their were built) and use natural names. > > After all when pyvault supports a new python on all distributions, > > all package will be built against it, and the few that need fixing > > will just depend on a slightly older python. > > > > I.e. the use model assumes that the pyvault maintainer and > > packager(s) test a new python version, approve it for becoming the > > next base version and rebuild everything against it. pyvault also > > provides the compatibility packages for other python packages not > > included in pyvault (like the vendor's), and also some python > > packages that won't build against the latest approved python version. > > > > It is also more maintainer friendly (i.e. don't support package pyfoo > > on multiple different python version, only one one). > > > > Does that model sound OK for you? > However, there is a weakness in RPM where it will automagically > Obsoletes previous versions of Python when executing an Upgrade. Which obsoletes are you thinking of? Are any really needed (other than replacing the vendor python with the pythonXX packages)? > But, the gist of it is to make available a set of packages that > maintains compatibility with existing python packages without impacting > those that Pyvault does not maintain (system-config-* and friends). That's perhaps unavoidable. If a pyvault user wants to have /usr/bin/python point to python 2.4 for his own pleasure and system-config-* and friends break with it, the you either need to educate users to use /usr/bin/python2.4 or rebuild applications to burn in the python version (like "#! /usr/bin/python2.2"). Here is a macro for that purpose: %python_burninversion find . -type f | grep -l "^#!.*python" | xargs perl -pi -e's,^(#!.*python)([^0-9.]*|$),${1}%python_version$2,' > I'd like to use natural names where possible, but the RPM issue with > Obsoletes still lurks. Providing unique package names with the > versioned Python inside of it is the only way to prevent this. I still don't see where the obsoletes enter. You mean python module packages, not the python packages, right? Why should python module ackages obsolete something? > * Do we really %ghost *.pyo? That's what I'm doing now as an experiment > discussed over at fedora.us. I'm not sure if Extras will have this > policy or not. > * Need to re-bytecompile applications for the latest version of python. > (see http://www.fifi.org/doc/mailman/README.Debian) Isn't this only an issue when installing into non-versioned python dirs, which one should not do? :) We aren't ghosting /urs/lib/lib*.so.* either with sources autobuilding when a new glibs/gcc is installed :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pyvault-devel/attachments/20041220/ac8767ad/attachment.pgp From Axel.Thimm at atrpms.net Mon Dec 20 19:38:50 2004 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Tue Dec 21 05:51:50 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <200412202353.12341.symbiont@berlios.de> References: <20041215115237.GA22486@neu.nirvana> <200412201456.41861.symbiont@berlios.de> <20041220111304.GD20677@neu.nirvana> <200412202353.12341.symbiont@berlios.de> Message-ID: <20041220183850.GC26948@neu.nirvana> On Mon, Dec 20, 2004 at 11:53:12PM +0800, Jeff Pitman wrote: > On Monday 20 December 2004 19:13, Axel Thimm wrote: > > > However, there is a weakness in RPM where it will automagically > > > Obsoletes previous versions of Python when executing an Upgrade. > > > > Which obsoletes are you thinking of? Are any really needed (other > > than replacing the vendor python with the pythonXX packages)? > > Ahhh! The *invisible* obsoletes, of course!! > > http://distro2.conectiva.com.br/pipermail/apt-rpm/2004-August/002513.html > http://lists.atrpms.net/pipermail/repo-coord/2004-August/000357.html > > I mean, I like your idea. It maps closer to Debian Python Policy, etc. > But, we cannot do it. I've tried with sweat and blood. It only brings > frustration when the Package itself (python) automatically removes > *any* and *all* packages that Provides: python = x.y.z, even if they're > named foobaz2.2, when python=2.3.4 is upgraded ... *boom*. Yes, I see, but is there need to provide "python" in all packages, especially the pythonXX ones? Most packages that explicitly require python do so with ">=". > > That's perhaps unavoidable. If a pyvault user wants to have > > /usr/bin/python point to python 2.4 for his own pleasure and > > system-config-* and friends break with it, the you either need to > > educate users to use /usr/bin/python2.4 or [...] > > I'd rather choose between educating users via FAQ or build a "python" > wrapper that flipped between versions. I'd rather not repackage the > whole nine yards. OK, then you have no issues at all with obsoletes, as the users only get to see pythonXX packages with no such provides, and keep their vendor python rpm (which does the provides/obsoletes game with his ancestors only). Only python developers need to take care to have proper python-devels packages that pull in the proper pythonXX packages. > > > * Do we really %ghost *.pyo? ?That's what I'm doing now as an > > > experiment discussed over at fedora.us. ?I'm not sure if Extras > > > will have this policy or not. > > > * Need to re-bytecompile applications for the latest version of > > > python. (see http://www.fifi.org/doc/mailman/README.Debian) > > > > Isn't this only an issue when installing into non-versioned python > > dirs, which one should not do? :) > > Well, if one does not package .pyo, they'll possibly get created if a > root user runs an application with -O as the flag. Whether executed > from the commandline or whether #!/usr/bin/python -O. So, in order for > a clean exit on a particular python, you'd want to make sure everything > is gutted by using %ghost. The reason they're not there is because the > intrinsic value of their existence versus the space consumption doesn't > match up. YMMV--just a blind experiment, I guess. > > This piece has a good summary: > https://www.redhat.com/archives/fedora-devel-list/2004-August/msg00249.html Oh, now I see. Definitely no %ghosting would be my suggestion from a security and setup POV. Any package assuming it may write arbitrary non-fingerprinted code into /usr/lib deserves to be shot on sight. The package either needs bytecompilation/optimization, which has to be done at package creation time, or does not. Consider read-only mounted /usr or a tripwire checking /usr. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pyvault-devel/attachments/20041220/a5ba4313/attachment.pgp From symbiont at berlios.de Tue Dec 21 17:16:20 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Tue Dec 21 17:19:30 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <20041220183850.GC26948@neu.nirvana> References: <20041215115237.GA22486@neu.nirvana> <200412202353.12341.symbiont@berlios.de> <20041220183850.GC26948@neu.nirvana> Message-ID: <200412220016.20639.symbiont@berlios.de> On Tuesday 21 December 2004 02:38, Axel Thimm wrote: > On Mon, Dec 20, 2004 at 11:53:12PM +0800, Jeff Pitman wrote: > > On Monday 20 December 2004 19:13, Axel Thimm wrote: > > > > However, there is a weakness in RPM where it will automagically > > > > Obsoletes previous versions of Python when executing an > > > > Upgrade. > > > > > > Which obsoletes are you thinking of? Are any really needed (other > > > than replacing the vendor python with the pythonXX packages)? > > > > Ahhh! The *invisible* obsoletes, of course!! > > [..] > > Yes, I see, but is there need to provide "python" in all packages, > especially the pythonXX ones? Most packages that explicitly require > python do so with ">=". To make it so that system-config-*, and others, don't get removed. To also allow for python23 or python24 to replace python without affecting other packages currently in the system. It's the implicit requires that really bite on these issues. > > > That's perhaps unavoidable. If a pyvault user wants to have > > > /usr/bin/python point to python 2.4 for his own pleasure and > > > system-config-* and friends break with it, the you either need to > > > educate users to use /usr/bin/python2.4 or [...] > > > > I'd rather choose between educating users via FAQ or build a > > "python" wrapper that flipped between versions. I'd rather not > > repackage the whole nine yards. > > OK, then you have no issues at all with obsoletes, as the users only > get to see pythonXX packages with no such provides, and keep their > vendor python rpm (which does the provides/obsoletes game with his > ancestors only). Not sure what you mean here, but there are pythonXY rpms. If the vendor python rpm happens to Provide: python-abi = X.Y, then whatever I have as modules should be good to go. Building the SRPM will be difficult, as that currently BuildRequires: python23-devel. So, as of now, the goal is: 1. To replace the vendor python rpm. 2. To provide latest python module and app packages. 3. To keep intact existing python module and app packages Pyvault has yet to deal with or does not want to deal with. > Only python developers need to take care to have proper python-devels > packages that pull in the proper pythonXX packages. python23-devel, python24-devel. > > > > * Do we really %ghost *.pyo? ?That's what I'm doing now as an > > > > experiment discussed over at fedora.us. ?I'm not sure if Extras > > > > will have this policy or not. [...] > > > > > > Isn't this only an issue when installing into non-versioned > > > python dirs, which one should not do? :) > > [...] > > This piece has a good summary: > > https://www.redhat.com/archives/fedora-devel-list/2004-August/msg00 > >249.html > > Oh, now I see. Definitely no %ghosting would be my suggestion from a > security and setup POV. Any package assuming it may write arbitrary > non-fingerprinted code into /usr/lib deserves to be shot on sight. > > The package either needs bytecompilation/optimization, which has to > be done at package creation time, or does not. Consider read-only > mounted /usr or a tripwire checking /usr. I never thought of it this way. It's in wide use in fedora.us and livna.org repos. I'll bring it up over in Fedora to see what the PowersThatBe think of it. Now, I'm leaning against %ghost. take care, -- -jeff From Axel.Thimm at atrpms.net Tue Dec 21 23:03:17 2004 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Tue Dec 21 23:03:29 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <200412220016.20639.symbiont@berlios.de> References: <20041215115237.GA22486@neu.nirvana> <200412202353.12341.symbiont@berlios.de> <20041220183850.GC26948@neu.nirvana> <200412220016.20639.symbiont@berlios.de> Message-ID: <20041221220317.GM20813@neu.nirvana> On Wed, Dec 22, 2004 at 12:16:20AM +0800, Jeff Pitman wrote: > On Tuesday 21 December 2004 02:38, Axel Thimm wrote: > > Only python developers need to take care to have proper python-devels > > packages that pull in the proper pythonXX packages. > > python23-devel, python24-devel. I'd prefer python-devel-2.3.4-xxx, python-devel-2.4.0-xxx. The reason is that python packages (modules and apps, not python itself) should have a plain BuildRequires: python-devel >= 2.2 Otherwise you end up rewriting specfiles for rebuilding packages on different pythons. Python package developers (PyVaultians? ;) need to take care to have a build-system that allows picking the right python-devel out of multiple. ypt/yum will always pull in the latest, which will be the right choice for most applications. python-devel could of course just be an intermediate stub for pythonXX-devel. Yes, the latest rpm features of implicit Provides/Obsoletes are rather interesting ... :/ (If I had a quick handle to patch them out, I surely would, the pain is rather high ...) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pyvault-devel/attachments/20041221/c7ff1aad/attachment.pgp From symbiont at berlios.de Wed Dec 22 01:19:37 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed Dec 22 01:23:10 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <20041221220317.GM20813@neu.nirvana> References: <20041215115237.GA22486@neu.nirvana> <200412220016.20639.symbiont@berlios.de> <20041221220317.GM20813@neu.nirvana> Message-ID: <200412220819.37367.symbiont@berlios.de> On Wednesday 22 December 2004 06:03, Axel Thimm wrote: > On Wed, Dec 22, 2004 at 12:16:20AM +0800, Jeff Pitman wrote: > > On Tuesday 21 December 2004 02:38, Axel Thimm wrote: > > > Only python developers need to take care to have proper > > > python-devels packages that pull in the proper pythonXX packages. > > > > python23-devel, python24-devel. > > I'd prefer python-devel-2.3.4-xxx, python-devel-2.4.0-xxx. The reason > is that python packages (modules and apps, not python itself) should > have a plain > > BuildRequires: python-devel >= 2.2 > > Otherwise you end up rewriting specfiles for rebuilding packages on > different pythons. I agree, except: 1. The package has a prefix of pythonXY in some instances. (eg., python23-twisted) 2. The package puts files into /usr/lib/python2.3/site-packages anyway. 3. The above scheme doesn't allow for multiple build areas python-devel = 2.4.0 will upgrade python-devel = 2.3.4. 4. If the above version *is* in the name, then that means BuildRequires should have that as part of the string or it won't compare the right package. (unless I'm missing a neat feature of rpm). > Python package developers (PyVaultians? ;) need to take care to have > a build-system that allows picking the right python-devel out of > multiple. ypt/yum will always pull in the latest, which will be the > right choice for most applications. Maybe. Need a more concrete example. Current version is based on the principal: "explicit is better than implicit". Only package developers are going to care, really. > python-devel could of course just be an intermediate stub for > pythonXX-devel. > > Yes, the latest rpm features of implicit Provides/Obsoletes are > rather interesting ... :/ Well, this "interesting" feature throws out any possibility for creating intermediate stubs. Play with Nasrat's provider spec yet? Make sure you have plenty of -Uvh going on to see the interaction. take care, -- -jeff From Axel.Thimm at atrpms.net Wed Dec 22 02:56:56 2004 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Wed Dec 22 02:57:02 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <200412220819.37367.symbiont@berlios.de> References: <20041215115237.GA22486@neu.nirvana> <200412220016.20639.symbiont@berlios.de> <20041221220317.GM20813@neu.nirvana> <200412220819.37367.symbiont@berlios.de> Message-ID: <20041222015656.GS20813@neu.nirvana> On Wed, Dec 22, 2004 at 08:19:37AM +0800, Jeff Pitman wrote: > On Wednesday 22 December 2004 06:03, Axel Thimm wrote: > > On Wed, Dec 22, 2004 at 12:16:20AM +0800, Jeff Pitman wrote: > > > On Tuesday 21 December 2004 02:38, Axel Thimm wrote: > > > > Only python developers need to take care to have proper > > > > python-devels packages that pull in the proper pythonXX packages. > > > > > > python23-devel, python24-devel. > > > > I'd prefer python-devel-2.3.4-xxx, python-devel-2.4.0-xxx. The reason > > is that python packages (modules and apps, not python itself) should > > have a plain > > > > BuildRequires: python-devel >= 2.2 > > > > Otherwise you end up rewriting specfiles for rebuilding packages on > > different pythons. > > I agree, except: > > 1. The package has a prefix of pythonXY in some instances. (eg., > python23-twisted) > 2. The package puts files into /usr/lib/python2.3/site-packages anyway. Can't this be (automatically) taken care of by macros and/or asking python/sys etc.? > 3. The above scheme doesn't allow for multiple build areas python-devel > = 2.4.0 will upgrade python-devel = 2.3.4. Yes, that was the comment on PyVaultians needing to have a clever buildsystem like say a pythonXX chroot for each pythonXX. > 4. If the above version *is* in the name, then that means BuildRequires > should have that as part of the string or it won't compare the right > package. (unless I'm missing a neat feature of rpm). Don't understand this, which BuildRequires are you thinking of? > > Python package developers (PyVaultians? ;) need to take care to have > > a build-system that allows picking the right python-devel out of > > multiple. ypt/yum will always pull in the latest, which will be the > > right choice for most applications. > > Maybe. Need a more concrete example. Current version is based on the > principal: "explicit is better than implicit". Only package developers > are going to care, really. Indeed. If it creates more issues than it solves, dump it :) > > Yes, the latest rpm features of implicit Provides/Obsoletes are > > rather interesting ... :/ > > Well, this "interesting" feature throws out any possibility for creating > intermediate stubs. It throws out concurrent package existance in general. :( > Play with Nasrat's provider spec yet? Make sure you have plenty of > -Uvh going on to see the interaction. I'm aware of the ugly rpm bug^Wfeature "all Provides are automatically obsoleting packages/Provides of the same name". Does Paul Nasrat's example demonstrate any further rpm regression? It's good to have someone inside of RH that understands there is a problem with the Provides/Obsoletes schema, let's hope it will create a solution ... :/ -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pyvault-devel/attachments/20041222/91231a1b/attachment.pgp From symbiont at berlios.de Wed Dec 22 03:44:13 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed Dec 22 03:47:30 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <20041222015656.GS20813@neu.nirvana> References: <20041215115237.GA22486@neu.nirvana> <200412220819.37367.symbiont@berlios.de> <20041222015656.GS20813@neu.nirvana> Message-ID: <200412221044.13844.symbiont@berlios.de> On Wednesday 22 December 2004 09:56, Axel Thimm wrote: > Does Paul Nasrat's > example demonstrate any further rpm regression? Nope. The purpose of provider is to just play with a stock spec template and see how upgrades, obsoletes, provides all interact with each other. It doesn't provide an example, per se. But, I already have a set of specs here that provide a clear, boiled-down sampling: http://symbiont.mn.sabren.com/sandbox/rpm/ See this for additional background and research on the issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352 thanks, -- -jeff From Axel.Thimm at atrpms.net Wed Dec 22 04:13:20 2004 From: Axel.Thimm at atrpms.net (Axel Thimm) Date: Wed Dec 22 04:13:43 2004 Subject: [PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3) In-Reply-To: <200412221044.13844.symbiont@berlios.de> References: <20041215115237.GA22486@neu.nirvana> <200412220819.37367.symbiont@berlios.de> <20041222015656.GS20813@neu.nirvana> <200412221044.13844.symbiont@berlios.de> Message-ID: <20041222031320.GW20813@neu.nirvana> On Wed, Dec 22, 2004 at 10:44:13AM +0800, Jeff Pitman wrote: > On Wednesday 22 December 2004 09:56, Axel Thimm wrote: > > Does Paul Nasrat's > > example demonstrate any further rpm regression? > > Nope. The purpose of provider is to just play with a stock spec > template and see how upgrades, obsoletes, provides all interact with > each other. It doesn't provide an example, per se. But, I already > have a set of specs here that provide a clear, boiled-down sampling: > > http://symbiont.mn.sabren.com/sandbox/rpm/ > > See this for additional background and research on the issue: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352 Thanks, I was already on this bug's Cc. Seems to be forgotten though. Packagers of all repos, unite against rpm's "features" and add your comments to this bug ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pyvault-devel/attachments/20041222/bbe1a098/attachment.pgp