[repo-coord] Re: dag, newrpms, kde-redhat, jpackage for FC1 (was: Dag FC1 repo for newer yum version)

[Axel Thimm]

Hi Dag,

On Fri, Aug 12, 2005 at 03:10:49AM +0200, Dag Wieers wrote:
> On Fri, 29 Jul 2005, Axel Thimm wrote:
> > Ccing repo-coord as this is more of interest there.
> > On Fri, Jul 29, 2005 at 12:12:00PM +1000, Michael Mansour wrote:
> > > http://apt.sw.be/fedora/1/en/i386/dag/
> > > 
> > > RPMS/                   28-Jul-2005 02:41    -   
> > > headers/                28-Jul-2005 02:41    -  
> > > 
> > > which doesn't contain the required repodata directory.
> > > 
> > > This seems to mean that when upgrading to yum 2.3.4, we lose access to Dag's
> > > repo which seems to be yum 2.0 compatible?
> > > 
> > > Is there a way to make this work?
> > 
> > Kindly asking Dag to provide the metadata support? :)
> 
> Axel, I regret you added the newer yum to older distributions. Not only 
> because you're replacing a core package (which you are free to do), but 
> mostly because you're forcing me to add yet another metadata to 
> distributions that we're trying to phase out instead of supporting in even 
> more ugly ways.
> 
> It might be easier for you, since people using your repository will have 
> this newer yum installed anyway. But you add complexity to everyone else, 
> as they have to support apt, old-yum and new-yum as well.

The reason for adding repomd to old distros is because for
yum-supported distros the yum version is performing really buggy (See
for instance #288 and #289 for the tip of the iceberg). I get support
calls on lists, bugzillas etc. that ATrpms is doing horrible things
when all that is horrible is the ancient yum version.

BTW ATrpms is not the only repo adding the newer repodata support to
old distributions, in medley-package-config I have listed
freshrpms,gstreamer,jpackage,kde-redhat as supporting repomd under
FC1. In fact ATrpms added repomd support rather late in the game.

> Seth should have foreseen backward compatibility (both within yum as well 
> as in yum-arch/createrepo) but since that's not the case I thing this was 
> a bad judgement call from you.

As Seth did not invest into backward compatibility or a transition
phase (there was a thread on the yum list, but the request was
discarded), ATrpms offers yum20 that works with the yum20 format for
all distros.

So in all distros you have tools support for all three metadatas, apt,
yum20 and repomd. ATrpms is extending w/o removing any
functionality. The choice remains at the user. Of course, one can
argue, if the user gets better tools, she wants to use them, too.

The past has often shown that keeping the package infrastucture,
e.g. rpm, apt, yum etc. up to date removes a lot of headaches
(remember the RH7.3 and RH8.0 rpm versions? ...).

There was no intention to place these headaches on somebody else's
head, but as I wrote, people can still use the yum20 metadata with
yum20, so nothing is really lost.

> I'm already spending 1 hour generating all metadata, which is causing 
> inflexibility and time-wasting on my end. Adding even more repodata will 
> only worsen this situation.
> 
> Unless we have a single application generating metadata for all formats, 
> I'm not interested in supporting new-yum on older distributions for that 
> reason.

I understand your point, and I'm in the same boat.

My recommendation (and AFAICT yours, too) would be to prefer smart
anyway which will work with the apt metadata.

How can I help you? In the long run distros using yum20 (I think only
FC1 and FC2) will die out. There are of course some RHEL clones using
also yum20 metadata. So for now it looks like we are still stuck with
yum20 metadata, unless we agree on upgrading yum on any distribution.

I think it would make sense to have a common subrepo of package
infrastructure ranging from rpm to yum, smart, apt, synaptic etc. that
will be shared between the repos and will ensure that users of any
distro have a sane set of tools to operate with. If the repos would
indeed coordinate this, then one could very well assume that yum20
metedata can be skipped.

The packages at ATrpms are already ATrpms-agnostic by not including
any repo config in the package itself and not depending on any
specific package name (there are only file dependencies on say
/etc/apt/apt.conf).

Would that be an option? I know that some fedora.us purists will cry
out lout that replacing rpm on RH7.3 is a deadly sin, because
replacing vendor packages is always a deadly sin, but I think the
benefits really outweigh any FUD/witchhunting.
-- 
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://lists.atrpms.net/pipermail/repo-coord/attachments/20050812/31ac5724/attachment.bin