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
Attachment:
signature.asc
Description: This is a digitally signed message part
