[repo-coord] Sub-Repo for Yum and Smart

[Jeff Pitman]

Hi:

Starting a new thread on this based on "dag, newrpms, kde-redhat,
jpackage for FC1 (was: Dag FC1 repo for newer yum version)" sent
earlier this month.

I've been reworking PyVault with a new base standard: CentOS 3/4 and FC
3/4. Due to the target being developers and bleeding edge folks for
the FC line, I dropped 1/2. Also, I have a target for those running
servers, thus, CentOS.

In my reworking, I dropped support for Apt. And, as the repos move
forward, I would encourage all to do the same. Especially since smart
has matured enough and it reuses md from other sources (ie xml-md).

I am willing to contribute to a micro-repo dedicated to providing a
common rpm, yum, and smart setup for at least the distros I mentioned
above. I'd also be willing to not continue the yum20 line at all; but,
I see that the political strings would be difficult to pull.

I've just barely completed work on getting yum 2.4.0 compiled and
running for the above. It also runs under python 2.4.1 on all
platforms. I've also distilled the python component out of RPM:

http://symbiont.mn.sabren.com/rpm-python/

And it works great. My next revision will strip out the configure
madness and focus totally on API defines rather than config.h. This
release also can compile under the different rpms distributed with the
above. So, it is possible to keep the vendor-supplied rpm.

Anyway, I started working on libxml2 stuff and thought, I should take
this from atrpms. Then, I looked at repo-coord and thought maybe we
should startup this discussion...

Thoughts?

[Axel Thimm]

Post by Jeff Pitman
In my reworking, I dropped support for Apt. And, as the repos move
forward, I would encourage all to do the same. Especially since smart
has matured enough and it reuses md from other sources (ie xml-md).
I am willing to contribute to a micro-repo dedicated to providing a
common rpm, yum, and smart setup for at least the distros I mentioned
above. I'd also be willing to not continue the yum20 line at all; but,
I see that the political strings would be difficult to pull.

Why not include apt and perhaps even yum20 in this common
infrastructure repo? This shouldn't promote actual generation of these
metadata for all repos, e.g. if we organise such a common repo, the
participants should be forced to create all metadata.

apt is still widely used, especially in older distros, and smart chews
with better performance on apt metadata than the repo-mds.

Post by Jeff Pitman
Anyway, I started working on libxml2 stuff and thought, I should take
this from atrpms. Then, I looked at repo-coord and thought maybe we
should startup this discussion...

I wouldn't mind, I would just need a copy of it in ATrpms to keep the
package set closed (and it should still build on the older distros).

It is also needed in a common infrastructure repo for a yum rpm.

[Jeff Pitman]

Post by Axel Thimm

Post by Jeff Pitman
I am willing to contribute to a micro-repo dedicated to providing a
common rpm, yum, and smart setup for at least the distros I
mentioned above. I'd also be willing to not continue the yum20
line at all; but, I see that the political strings would be
difficult to pull.

Why not include apt and perhaps even yum20 in this common
infrastructure repo?

Either way, I was just throwing it out as a discussion point.

Post by Axel Thimm

Post by Jeff Pitman
Anyway, I started working on libxml2 stuff and thought, I should
take this from atrpms. Then, I looked at repo-coord and thought
maybe we should startup this discussion...

I wouldn't mind, I would just need a copy of it in ATrpms to keep the
package set closed (and it should still build on the older distros).
It is also needed in a common infrastructure repo for a yum rpm.

Just curious, I have been studying this some more. You provide a direct
upgrade of 2.5.10 to 2.6.19 from atrpms, however, it doesn't appear
that you've attempted to rectify ABI problems with the upgrade. The
deps work out in favor of this upgrade; but, do the programs such as
memprof, scrollkeeper, kdelibs, etc. etc. all actually function
properly?

For example, gstreamer shows:

[***@plain pyvault]$ ldd /usr/lib/libgstreamer-0.6.so
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00111000)

No one has seen any problems with this? Also, if we were to attempt to
keep the Core libs and files intact, how would we provide 2.5.10
through this link?

thanks,

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm

Post by Jeff Pitman
I am willing to contribute to a micro-repo dedicated to providing a
common rpm, yum, and smart setup for at least the distros I
mentioned above. I'd also be willing to not continue the yum20
line at all; but, I see that the political strings would be
difficult to pull.

Why not include apt and perhaps even yum20 in this common
infrastructure repo?

Either way, I was just throwing it out as a discussion point.

Post by Axel Thimm

Post by Jeff Pitman
Anyway, I started working on libxml2 stuff and thought, I should
take this from atrpms. Then, I looked at repo-coord and thought
maybe we should startup this discussion...

I wouldn't mind, I would just need a copy of it in ATrpms to keep the
package set closed (and it should still build on the older distros).
It is also needed in a common infrastructure repo for a yum rpm.

Just curious, I have been studying this some more. You provide a direct
upgrade of 2.5.10 to 2.6.19 from atrpms, however, it doesn't appear
that you've attempted to rectify ABI problems with the upgrade.

There is backward ABI compatibility, which is why the major lib
version hasn't been bumped. If not, then upstream development would
had been very sloppy.

Post by Jeff Pitman
The deps work out in favor of this upgrade; but, do the programs
such as memprof, scrollkeeper, kdelibs, etc. etc. all actually
function properly?
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00111000)
No one has seen any problems with this?

No, and libxml bugs surface pretty soon, at the very least in kdelibs.

Post by Jeff Pitman
Also, if we were to attempt to keep the Core libs and files intact,
how would we provide 2.5.10 through this link?

You can't. If a project has N releases with libfoo.so.7 where would
you put the N-1 other libfoo.so.7?

[Jeff Pitman]

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm
I wouldn't mind, I would just need a copy of it in ATrpms to keep
the package set closed (and it should still build on the older
distros).
It is also needed in a common infrastructure repo for a yum rpm.

Just curious, I have been studying this some more. You provide a
direct upgrade of 2.5.10 to 2.6.19 from atrpms, however, it doesn't
appear that you've attempted to rectify ABI problems with the
upgrade.

There is backward ABI compatibility, which is why the major lib
version hasn't been bumped. If not, then upstream development would
had been very sloppy.

Thanks!

Right now, my approach probably deviates slightly from what you've done
at atrpms. This is due to trying to keep in line with what currently
is done at pyvault. I'll extract -python completely from libxml2.spec
and put it into libxml2-python.spec, then I'll use my buildsystem to
output packages for python 2.2/2.3/2.4 where needed. I discussed
rpm-py in a previous email. (I just released a new rpm-py that guts
the configure mantra, thus, speeding up compile time.) This keeps rpm
at the same version as delivered with the distro in question. Not sure
if I want to upgrade this yet.

Anyway, if you see ways we can continue to collaborate, let me know.

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm

Post by Jeff Pitman

Post by Axel Thimm
I wouldn't mind, I would just need a copy of it in ATrpms to keep
the package set closed (and it should still build on the older
distros).
It is also needed in a common infrastructure repo for a yum rpm.

Just curious, I have been studying this some more. You provide a
direct upgrade of 2.5.10 to 2.6.19 from atrpms, however, it doesn't
appear that you've attempted to rectify ABI problems with the
upgrade.

There is backward ABI compatibility, which is why the major lib
version hasn't been bumped. If not, then upstream development would
had been very sloppy.

Thanks!
Right now, my approach probably deviates slightly from what you've done
at atrpms. This is due to trying to keep in line with what currently
is done at pyvault. I'll extract -python completely from libxml2.spec
and put it into libxml2-python.spec, then I'll use my buildsystem to
output packages for python 2.2/2.3/2.4 where needed.

That sounds awfully familiar :)

http://atrpms.net/name/libxml2-python24/

Post by Jeff Pitman
I discussed rpm-py in a previous email.

I missed that one, what is rpm-py? google returns hits on rpm.py
instead.

Post by Jeff Pitman
(I just released a new rpm-py that guts the configure mantra, thus,
speeding up compile time.) This keeps rpm at the same version as
delivered with the distro in question. Not sure if I want to
upgrade this yet.

Is that perhaps the same like or similar to
http://atrpms.net/name/rpm-python/?

Post by Jeff Pitman
Anyway, if you see ways we can continue to collaborate, let me know.

[Jeff Pitman]

Post by Axel Thimm

Post by Jeff Pitman
Right now, my approach probably deviates slightly from what you've
done at atrpms. This is due to trying to keep in line with what
currently is done at pyvault. I'll extract -python completely from
libxml2.spec and put it into libxml2-python.spec, then I'll use my
buildsystem to output packages for python 2.2/2.3/2.4 where needed.

That sounds awfully familiar :)
http://atrpms.net/name/libxml2-python24/

Yeah, I know you got that one. Mine is a slight modification using a
%{python} macro which expands to python24/23/22 driven by the build
system. If it's not defined it defaults to python. I'll post linkage to
specs, etc. after I test stuff. (I also like to do anything in my power
to avoid a rebuild of the entire lib. Just configure and then run
distutils build in the python directory.)

Post by Axel Thimm

Post by Jeff Pitman
I discussed rpm-py in a previous email.

I missed that one, what is rpm-py? google returns hits on rpm.py
instead.

See below.

Post by Axel Thimm

Post by Jeff Pitman
(I just released a new rpm-py that guts the configure mantra, thus,
speeding up compile time.) This keeps rpm at the same version as
delivered with the distro in question. Not sure if I want to
upgrade this yet.

Is that perhaps the same like or similar to
http://atrpms.net/name/rpm-python/?

http://symbiont.mn.sabren.com/rpm-python/

I've been coordinating with jbj and pnasrat on it. Much smaller and
builds fast. Mainly a convenience issue for me. Also, it builds
against the rpmlib installed externally instead of relying on the
topdir. This allows one to build against whatever rpm was distributed
for a particular release.

So, it's got a similar goal to your rpm-python, but with some tweaks to
it.

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm

Post by Jeff Pitman
Right now, my approach probably deviates slightly from what you've
done at atrpms. This is due to trying to keep in line with what
currently is done at pyvault. I'll extract -python completely from
libxml2.spec and put it into libxml2-python.spec, then I'll use my
buildsystem to output packages for python 2.2/2.3/2.4 where needed.

That sounds awfully familiar :)
http://atrpms.net/name/libxml2-python24/

Yeah, I know you got that one. Mine is a slight modification using a
%{python} macro which expands to python24/23/22 driven by the build
system. If it's not defined it defaults to python.

OK, we're on the same track here. I just prefer to have the specfile
point to python and control python from the outside (in the chroot).

Post by Jeff Pitman
http://symbiont.mn.sabren.com/rpm-python/
I've been coordinating with jbj and pnasrat on it. Much smaller and
builds fast. Mainly a convenience issue for me. Also, it builds
against the rpmlib installed externally instead of relying on the
topdir. This allows one to build against whatever rpm was distributed
for a particular release.

Oh yes, that's very cool! I hope Paul will use these modifications, or
even better split the python bindings off the rpm release.

Post by Jeff Pitman
So, it's got a similar goal to your rpm-python, but with some tweaks to
it.

[Jeff Pitman]

Post by Axel Thimm

Post by Jeff Pitman
http://symbiont.mn.sabren.com/rpm-python/
I've been coordinating with jbj and pnasrat on it. Much smaller and
builds fast. ?Mainly a convenience issue for me. ?Also, it builds
against the rpmlib installed externally instead of relying on the
topdir. This allows one to build against whatever rpm was
distributed for a particular release.

Oh yes, that's very cool! I hope Paul will use these modifications,
or even better split the python bindings off the rpm release.

I thought about hacking the same approach out for libxml2. But, they
changed their libxml2-api.xml content between their releases which
blows up the generator. So, it makes it nasty. rpm has kept things
really stable in their api. 4.4.x python bindings compile pretty ok
with 4.2.x. Had to drop the PLD-requested rpmds_BT function. jbj says
it's ok and they don't use it anyway.