Re: dag, newrpms, kde-redhat, jpackage for FC1 (was: Dag FC1 repo for newer yum version)
Axel Thimm <[email protected]> Fri, 12 Aug 2005 13:55:11 +0200
| Newsgroups | gmane.linux.redhat.rpm.atrpms.repo-coordination,gmane.linux.redhat.rpm.atrpms.general |
|---|---|
| Message-ID | <[email protected]> |
--===============6264350928667567974== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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/ > > >=20 > > > RPMS/ 28-Jul-2005 02:41 - =20 > > > headers/ 28-Jul-2005 02:41 - =20 > > >=20 > > > which doesn't contain the required repodata directory. > > >=20 > > > This seems to mean that when upgrading to yum 2.3.4, we lose access t= o Dag's > > > repo which seems to be yum 2.0 compatible? > > >=20 > > > Is there a way to make this work? > >=20 > > Kindly asking Dag to provide the metadata support? :) >=20 > Axel, I regret you added the newer yum to older distributions. Not only= =20 > because you're replacing a core package (which you are free to do), but= =20 > mostly because you're forcing me to add yet another metadata to=20 > distributions that we're trying to phase out instead of supporting in eve= n=20 > more ugly ways. >=20 > It might be easier for you, since people using your repository will have= =20 > this newer yum installed anyway. But you add complexity to everyone else,= =20 > 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= =20 > as in yum-arch/createrepo) but since that's not the case I thing this was= =20 > 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=20 > inflexibility and time-wasting on my end. Adding even more repodata will= =20 > only worsen this situation. >=20 > Unless we have a single application generating metadata for all formats,= =20 > I'm not interested in supporting new-yum on older distributions for that= =20 > 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. --=20 Axel.Thimm at ATrpms.net --yEPQxsgoJgBvi8ip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC/I4fQBVS1GOamfERAkFiAJoCpiJ9rD98dw7+BwuLTMwbm+BHIACeMOzI I5oJjAZQyIXDbgoFHXs6zBo= =Ozc0 -----END PGP SIGNATURE----- --yEPQxsgoJgBvi8ip-- --===============6264350928667567974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ repo-coord mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/repo-coord --===============6264350928667567974==--