Suggestion for a new Download page

[Jonas Pasche]

Hi Eric,

> It is a trade off.  If we do that, we remove the encouragement to use our
> apt/yum packages...

Good point!

> Actually, I was told yum would use multiple channels as 'fail-over' channels
> in the case a server was down, and would use them in the order provided
> in the config file.  Is this not true, or am I missing the point, or what?

Not exactly true: One can give yum more than one baseurl for a specific
channel, which means that one channel cannot failover to another
channel, but one channel has different sources where packages of this
channel can be retrieved. Normally all these sources contain an
equivalent package set.

apt downloads package lists from any given repository first. Having the
same channel mentioned on more than one repository means that its
package list will be downloaded more than once. In cases of big channels
like "os", this will take a considerable amount of time; that's why I
suggested the removal of duplicate channels in apt's sources.list, at
least for "os" which is by far the biggest. For yum, this shouldn't be a
problem, because it would only touch the second source for the "base"
channel if the first isn't available.

However, I see a problem in that channels are not necessarily
equivalent. "updates" on freshrpms only provides Red Hat updates;
"updates" on Fedora Legacy provides Red Hat updates plus legacy updates.
With apt, this shouldn't be a big problem, because apt downloads any
package list and then selects the most recent version of a package,
which will automatically select legacy packages over Red Hat updates.
The only tradeoff, again, is that package lists for equivalent channels
have to be downloaded more than once.

With yum, the user has to make sure that he lists our update channel
_before_ any other update channel that possibly doesn't contain legacy
updates. Say you have repository X that provides Red Hat updates (but no
legacy updates), and it is listed before ours. yum will download the
package list from there and simply wouldn't know that there are even
more updates because it doesn't touch the second repository (which might
point to download.fedoralegacy.org) until the first _fails_. That's why
I suggested to keep only one updates channel.

After thinking about this, I see that my annotations are not necessarily
equivalent for both apt and yum. I'll see if I can make a better
proposal for them, because it think it's important.

> I do understand we would want ours first if not the only entries for base/os
> channels, but I'm curious about the working, etc.

I fear I don't understand what you mean with that.

> I know nothing about that, as I don't know how to configure apt.  So to
> provide such a thing, I'd need the info (files) provided to me.

I have posted apt configuration a few days ago. Here again:

Red Hat Linux 7.2:
rpm http://download.fedoralegacy.org/apt redhat/7.2/i386 os updates legacy-utils

Red Hat Linux 7.3:
rpm http://download.fedoralegacy.org/apt redhat/7.3/i386 os updates legacy-utils

Red Hat Linux 8.0:
rpm http://download.fedoralegacy.org/apt redhat/8.0/i386 os updates legacy-utils

This is copy+paste information to put into /etc/apt/sources.list.

It's a one-liner per distribution release, in contrast to the
mirrors.list file that (1) has this one line splitted into three
different lines, (2) has mirrors.list-specific additions that cannot be
put into the sources.list file and (3) doesn't have a prefix of "rpm "
which is needed in the sources.list file, but not in the mirrors.list
file (mirror-select.lua would generate sources.list configuration out of
the mirrors.list file, but they don't share the same file format).

> I thought about that, and am willing to do so, as long as the people involved
> are okay with it.  I was thinking maybe just first names for now?  (If we
> hit an duplicate first name, add a last initial or something).

Would be okay for me.

Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20040205/05cfa2b7/attachment.sig>