Discussion:
[repo-coord] dag, newrpms, kde-redhat, jpackage for FC1 (was: Dag FC1 repo for newer yum version)
Axel Thimm
2005-07-29 16:16:04 UTC
Permalink
Ccing repo-coord as this is more of interest there.
[...]
medley-package-config-99-1.rhfc1.at
this seemed to contain everything I wanted (actually more than I wanted) but
[newrpms.sunsite.dk]
name=Fedora Core $releasever NewRPMS.sunsite.dk
baseurl=http://newrpms.sunsite.dk/apt/redhat/en/i386/fc$releasever
which I added myself as a repo drop file.
But only for yum20 headers, or even yum 2.3.x? There is no repodata
dir there.
Anyway, running a "yum check-update", al the kde-redhat and jpackage stuff
Hm, they used to ship FC1 repos. I see that kde-redhat removed the FC1
repo. But jpackage for FC1 with the new yum format should still be alive at
http://mirrors.sunsite.dk/jpackage/1.6/fedora-1/free
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? :)

But my personal recommendation is to use smart. smart can access both
apt and yum repos (but not yum20 repos), so smart does have the
largest set of packages available. There are still (with FC4) some
repos that only export apt metadata.

Thanks for the feedback on medley-package-config for FC1. I'll wait a
couple of days to see whether any repo maintainer will change anything
and will fix medley-package-config.
--
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/20050729/59739660/attachment.bin
Dag Wieers
2005-08-12 08:12:37 UTC
Permalink
Post by Axel Thimm
Ccing repo-coord as this is more of interest there.
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.

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.

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.

Kind regards,
-- dag wieers, ***@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
Axel Thimm
2005-08-12 18:55:30 UTC
Permalink
Hi Dag,
Post by Dag Wieers
Post by Axel Thimm
Ccing repo-coord as this is more of interest there.
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.
Post by Dag Wieers
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.
Post by Dag Wieers
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
Dag Wieers
2005-08-23 23:06:56 UTC
Permalink
Post by Dag Wieers
Post by Axel Thimm
Ccing repo-coord as this is more of interest there.
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? :)
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 reconsidered, now that createrepo has md5 caching support I added
new-yum metadata support for all the Fedora repositories.

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

Loading...