On Wed, 2014-11-05 at 14:43 -0500, Gene Czarcinski wrote: > OK, I am sure you guys know what you are talking about but it is a > little vague to me. Just what are all these repos? We've cleaned this up now, but just to write it down one more time for the record: The repos in question are the fedora-workstation.repo , fedora-server.repo and fedora-cloud.repo repos that were packaged in fedora-repos-anaconda around the time of Alpha. The *original* plan was that there would be Server, Workstation and Cloud network install images that would, by default, offer *only* the package groups those products considered part of their product. The design for achieving this was that each of those images would have the fedora-(product).repo for that Product as its base repository. Those repos are/were configured to use mirrormanager with a URL like: https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-workstation-21&arch=x86_64 which was intended at pre-release time to point to either the latest TC/RC in staging, e.g.: https://dl.fedoraproject.org/pub/alt/stage/21_Alpha_RC1/Workstation/x86_64/os/ and/or to the current frozen milestone tree, e.g.: https://dl.fedoraproject.org/pub/fedora/linux/releases/test/21-Alpha/Workstation/x86_64/os/ (I don't recall if we ever actually nailed down precisely when the mirrormanager redirect would point to which, but I guess it doesn't matter too much now). Those trees indeed contained only the package groups each Product wanted (according to the kickstarts used to create them). For Alpha we actually implemented all that, so there was a Workstation network install image that used fedora-workstation.repo as its base repository and a Server network install image that used fedora-server.repo as its base repository. However, it turned out that didn't work quite as intended. anaconda is by default quite 'greedy' when it comes to repositories - without an explicit configuration it'll use any valid ones it finds (in /etc/anaconda.repos.d) as supplementary repositories. It reads comps info from supplementary repositories. So although the 'Product-specific' network install images used the correct pruned repository as their *base* repository, they still offered the full range of package groups, because they found them in fedora.repo , which was also present on the network install images. Removing fedora.repo from the images would've been a bit tricky but probably possible somehow or other, but when I tested to check that that would be enough to solve the problem, it turned out it wouldn't. anaconda would also use fedora-updates.repo as a supplementary repository in all cases, and fedora-updates-testing.repo as a supplementary repo prior to release. Prior to release, updates-testing usually has a full set of comps data, and post-release, updates usually does. So even if you removed fedora.repo from the images, the group list wasn't filtered as expected, because anaconda would get the groups data from one of the updates repos. We spent a bit of time kicking around ways to "solve" that but there really aren't any very good ones. It's not even as simple as 'how can we remove the updates repositories from the images', because we actually *want* them to be available for people to get updated packages during install. So what we wound up doing instead was saying "you know what, no-one really *wants* these Product-specific network installs in any case. Everyone seems to be happy with us just officially shipping the Server one, with Server as the *default* package group but all the other package groups available, so the Server image also works for doing network installs of Workstation and Cloud. We want to make network install *possible* for particular use cases for those products, but it's not the primary distribution method and doesn't need a clever Product-specific image." (Really, what we're now calling the 'Server network install image' is pretty much exactly what the plain old 'network install image' was for all previous releases). So for Alpha and Beta we just left in all the crap we'd done to try and make the images Product-specific, but said it was totally fine that it didn't work. For Beta we dropped the Workstation installer tree from the mirrors entirely, and we fixed comps so that Server is the default package group. This *works*, but it leaves around a bunch of crap we don't really need. We have a line in lorax which pulls in the 'product-specific' repositories to the network install images, even though we don't need them any more - so when you do an Alpha or Beta network install anaconda is actually setting up all of fedora-server.repo , fedora-workstation.repo and fedora-cloud.repo , even though they're entirely useless and it'd be just fine using only fedora.repo . We also have to keep the Product repositories set up in mirrormanager, or else network installs will start failing because they can't configure the base repository (which is still the Product-specific repository). So what bcl just did yesterday was stop lorax from pulling in the product-specific repositories when composing images any more, and re-instate a change from very early Alpha days, before we actually put the Product-specific repos in place, which tells anaconda to use 'fedora' as the base repository for Fedora installs (as it did before the whole Product kerfuffle). That's what this change is: https://git.fedorahosted.org/cgit/anaconda.git/commit/?id=9b96d5f6d3f1d728960465573816ae3a50b78c73 productName(), if you trace out the code, ultimately turns out to be 'the value of PRODUCT in /.buildstamp'. Which for a Product-ized Fedora, is "Fedora-(Product)". e.g. for Server, it's "Fedora-Server". So, when the line reads: DEFAULT_REPOS = [productName.lower(), "rawhide"] it makes DEFAULT_REPOS a list containing the strings 'fedora-server' and 'rawhide', and that means anaconda will try to use a repository named 'fedora-server' as its base repo, and if that doesn't work it'll try and use 'rawhide', and if that doesn't work it'll go sit in a corner and cry. i.e., when the line looks like that, we're expecting there to be a 'Product-ized' repo for anaconda to use. When instead the line reads: DEFAULT_REPOS = [productName.split('-')[0].lower(), "rawhide"] it makes DEFAULT_REPOS a list containing the strings 'fedora' and 'rawhide' (because we split "Fedora-Server" with - as the separator, take the first of the strings that results from the split, and lowercase it). anaconda will try to use the repository named 'fedora' as its base repository. i.e., when the line looks like that, we're *not* looking for a Product-ized repo, we're just using the universal, non-Product-y 'fedora' repository. This is what was used as the base repo in previous releases - before we had Products, the PRODUCT value in /.buildstamp was just "Fedora", so the simpler version of the line would produce 'fedora'. (Happily we don't have to worry too much about RHEL or CentOS here, because there's no such thing as a 'default' network install for those - if you boot their netinst images, they don't successfully discover mirrors automatically. You have to explicitly provide a source, interactively, on the command line, or in your kickstart.) I guess it gets slightly confusing because in order to produce more or less the *same* behaviour as F20 we have to *change* anaconda (change the DEFAULT_REPOS line), whereas if we *don't* change the DEFAULT_REPOS line we get *different* behaviour from F20. But that's all that's going on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
