[repo-coord] disttags, useful?? (was Re: python 2.3 for RH7.3)

[Jeff Pitman]

(moved this out to repo-coord)

Background Info

Pondering upon the true usefulness of disttags given observations seen
while performing apt-get dist-upgrade.

I guess you must have had a bad repo in the set. The sets I have
successfully been upgrading were
vendor/atrpms/freshrpms/newrpms/dag/kde-redhat.

So, there's a lot of resulting cruft
unless we could somehow detect that among all the active repos
whether a particular version of a package is really needed. Pretty
tough hurdle to jump over.

Now that you mention it I remember that freshrpms and perhaps even
dag removed the epochs from their packages at some time
(rh9?). Unfortunatley epochs are fatal sins, once there you may not
remove them, otherwise you get effects like the ones you describe.

My gut feeling without any anecdotal evidence is that Epochs aren't the
only problem. Another issue could be package renames between distro
versions, such as libgal2.0_6 versus libgal2 or other small tweaks like
this. One other, I'd like to highlight, is the existence of rhfc2
packages in ATrpms, Dag, Freshrpms, CCRMA, etc. Yes, since the glibc
and base packages between fc2 && fc3 provide the same, these are good
to go. So, what's the usefulness?

Therefore, it is my belief that delegating this high level function to
another mechanism rather than utilizing the existing depresolver via
Release: would be more flexible and more useful.

Apart from that the concept of each repo until now is to ensure
proper upgradablity. If that is not sustained it's a bug in the repo.

Unfortunately, we don't have enough testing in the dist-upgrade arena.
So, I believe that dist-upgrade is the only target usefulness for
disttags. However, since this happens on a per machine basis maybe
once every 1 or 2 years depending on required stability, it's real
tough to get anything out of it.

So, cases against disttag usefulness:

1. Same repo, but later distro no longer provides package because it's
been put into Fedora Core/Extras.
2. Package renames. (libgal2.0_6 versus libgal2)
3. Reuse of packages just used in another distro (fc2 versus fc3)
4. epoch'd disttag vs. "rhfc2"; migration to rhfc2 format requires an up
on the Release for all packages.

Anyway, there might be other issues, but I feel these provide a
compelling look at a possible rethink on disttags. Let me know where
I've gone absolute mad.

take care,

[Jeff Pitman]

Post by Jeff Pitman
Anyway, there might be other issues, but I feel these provide a
compelling look at a possible rethink on disttags. ?

Oh, and disttags causes us to go crazy about things like: where do we
fit el3 or el2 in the line from rh9 -> fc3? Trying to order different
lines of distros in some linear sequence doesn't work.

So, I'm just advocating Smart to be able to do a "dist-change", instead
of upgrade and take what your current system has to any other distro.
This would make possible crazy things like el2 -> chaos -> el3 -> fc3
possible. Having such a mechanism would deprecate the entire idea of
having disttags, making our Release munges a lot more manageable.

take care,

[Dag Wieers]

Post by Jeff Pitman

Post by Jeff Pitman
Anyway, there might be other issues, but I feel these provide a
compelling look at a possible rethink on disttags. ?

Oh, and disttags causes us to go crazy about things like: where do we
fit el3 or el2 in the line from rh9 -> fc3? Trying to order different
lines of distros in some linear sequence doesn't work.

For different distros it does not work. But as someone once said:

Rawhide -> unstable
Fedora -> testing
Red Hat -> stable

If you consider this and you know el4 is extracted from fc3, it may make
sense to allow people to upgrade from fc3 to el4. Just like I know in
production rh7 is upgraded to el3 with little problems.

It may not be supported but it works and you can even do it remotely
without any problems. (I've done it several times with no problems)

Post by Jeff Pitman
So, I'm just advocating Smart to be able to do a "dist-change", instead
of upgrade and take what your current system has to any other distro.
This would make possible crazy things like el2 -> chaos -> el3 -> fc3
possible. Having such a mechanism would deprecate the entire idea of
having disttags, making our Release munges a lot more manageable.

Smart may be a solution, but disttags don't really harm. I'm not sure why
people think disttags or repotags are harmful and should be removed from
Release tags.

-- dag wieers, ***@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]

[Jeff Pitman]

Post by Dag Wieers

Post by Jeff Pitman
possible. Having such a mechanism would deprecate the entire idea
of having disttags, making our Release munges a lot more
manageable.

Smart may be a solution, but disttags don't really harm. I'm not sure
why people think disttags or repotags are harmful and should be
removed from Release tags.

Not harmful, per se, they're just very misleading. Especially now that
fc2 packages are applicable to the fc3 distribution. It certainly
makes no sense to use it when a package applies to multiple distros--
noarch is an extreme example where I think we all agree that dropping
this is OK.

Before, when running a dist-upgrade from rh9 to fc2, I found a bunch of
"rpm -qa | grep rh9" packages littering the rpm package landscape. It
was a great thing to have this indicator since several programs I used
daily were in a broken state after that upgrade. The observations I
found--which I have shared a few times--are: 1) package renames, 2)
package dropped or moved to another repo, 3) repenting of epoch, etc.

To truly do a dist-upgrade, one must "prep" the system, so to speak, to
take care of issues with the change in system. At this point, one must
apt-get install addthis rmthat- addver=2.3.1-2 rmthis-, etc. to get it
in a sane state where a full dist-upgrade can successfully occur.
(This is where the freshrpms "apt-shell" discussion is leading to.)

Therefore, if the only reason a disttag exists is to facilitate a
forward distribution upgrade, then I believe we are wasting time
arguing about the syntax when the semantics can't even address the
issues at hand. What can address them is more intelligence in higher
level package handlers such as smart or apt-get. (I'd include yum, but
the author as a negative stance on dealing with dist-upgrade issues.)

Anyhoo... most of this doesn't really matter except for the fact the
accelerated schedule in Fedora releases. Having a solid, workable
dist-upgrade solution would make a lot of users extremely happy! ;) I
just don't see disttags leading us there.

take care,

[Axel Thimm]

Post by Jeff Pitman

Post by Dag Wieers

Post by Jeff Pitman
possible. Having such a mechanism would deprecate the entire idea
of having disttags, making our Release munges a lot more
manageable.

Smart may be a solution, but disttags don't really harm. I'm not sure
why people think disttags or repotags are harmful and should be
removed from Release tags.

Not harmful, per se, they're just very misleading. Especially now that
fc2 packages are applicable to the fc3 distribution.

This has been always the case, most rh9 packages should still be
installable under fc3, I guess. It just makes more sense to use the
build toolchain of the newer distribution.

What perhaps made you think that fc2 and fc3 have a special
releationship is that fedora.us has not published fc3 packages yet and
points to its fc2 repo.

The idea of <buildid><disttag><more> is to have different builds
(<disttag>) of the same sources/patches/config (<buildid>). Placing it
that way makes

o newer buildid always win regardless of the <disttag>, e.g. when a
newer disttag does not even exist (like in fedora.us' case)
o higher disttags win, when the buildid is the same, e.g you point to
fc2 and fc3 repos or still hav efc2 packages on a fc3 system.

Since distro-transitions _can_ be smooth the problem's solution must
be done on a fine grained rpm-level, tools like apt or smart can paste
over certain problems, but it's better to have a solution that every
package manager including bare rpm can cope with like disttags.

As a rule of thumb: Don't use disttags for packages truly distribution
independent like firmware, fonts, non-compiled scripts and the like,
otherwise if the packages would yield binary different content for
different distributions use disttags.

[Jeff Pitman]

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

I've been doing some thinking around this. How about the following
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 Pitman]

Post by Jeff Pitman
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

[Axel Thimm]

I've been doing some thinking around this. How about the following
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 :)

[Jeff Pitman]

Post by Axel Thimm

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

Post by Axel Thimm

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.

Post by Axel Thimm

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.

Post by Axel Thimm

* 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,

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm

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 ">=".

Post by Jeff Pitman

Post by Axel Thimm
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.

Post by Jeff Pitman

Post by Axel Thimm

* 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.
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.

[Jeff Pitman]

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm

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.

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm
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.

Post by Axel Thimm
Only python developers need to take care to have proper python-devels
packages that pull in the proper pythonXX packages.

python23-devel, python24-devel.

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm

* 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? :)

[...]
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,

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm
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 ...)

[Jeff Pitman]

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm
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).

Post by Axel Thimm
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.

Post by Axel Thimm
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,

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm
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.

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.?

Post by Jeff Pitman
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.

Post by Jeff Pitman
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?

Post by Jeff Pitman

Post by Axel Thimm
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 :)

Post by Jeff Pitman

Post by Axel Thimm
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. :(

Post by Jeff Pitman
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 ... :/

[Jeff Pitman]

Post by Axel Thimm
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,

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm
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
http://symbiont.mn.sabren.com/sandbox/rpm/
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 ;)