Re: [Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
On Fri, Jul 25, 2014 at 01:44:40PM -0400, Mike Pinkerton wrote: Mattdm then followed with 2 1/2 additional topics: 1a. Identifying different Fedora products -- fedora-release-* contents and /etc/os-release As I understand it, you are trying to decide where and how to set a flag that will signal the product that is either installed or to be installed. There was mention of dropping product specific snippets in /usr/lib/os-release.d/ as one solution. Does it have to be any more complex than the approach used by systemd? If fedora-release were to drop all product specific snippets in /usr/lib/os-release.d/, then a system admin could use a symbolic link in /etc/os-release.d to flag which product (or no product) he wanted installed. Similar to: So, one catch is that os-release.d, with snippets, isn't currently supported by the upstream standard. (If there is work to make it so, awesome.) And it's not completely trivial, because either /etc/os-release needs to be regenerated on change to the .d snippets, or else software which reads that file (like agetty) needs to be updated to follow the .d directory too. But also, ideally, the contents of /etc/os-release aren't just notes -- they actually reflect the state of the system. Having it managed by RPM (or some higher-level tool, theoretically) is helpful there. Here: Then, if a system admin wanted to change the box to a server, or to a non-productized box, he could simply change the symbolic link to: /etc/os-release.d/product - /usr/lib/os-release.d/server.product the _name_ has changed, but you don't necessarily have any of the actual software (either installed or running) that makes it Fedora Server. That's significantly less useful. /etc/os-release.d/product - /usr/lib/os-release.d/generic.product and then run whatever product syncing tool you develop -- perhaps: dnf product-sync Okay, so, yeah -- something like that would be needed. But if we're gonna have such a tool, might as well make it also update the os-release information. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
On Mon, Jul 28, 2014 at 12:28:11PM -0400, Miloslav Trmač wrote: I appreciate your continued consideration of this item. I'm not clear on how Anaconda is supposed to work with different products, but if it is reading whatever product flag you set in order to determine the package list, couldn't a single netinstall CD work for all products, as well as a generic, non-productized install, assuming that there were a place in the UI to specify which product the user wanted installed? Actually, this seems to already be the case. A netinstall is produced as a Fedora Server deliverable, but it can be used to install a non-Product system, and, if other Products adopted the same conventions, also any other Product. But does anyone own that netinstall working in this way? Presumbably Server only cares about it being able to install Server, and the rest is a side-effect. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
- Original Message - On Mon, Jul 28, 2014 at 12:28:11PM -0400, Miloslav Trmač wrote: couldn't a single netinstall CD work for all products, as well as a generic, non-productized install, assuming that there were a place in the UI to specify which product the user wanted installed? Actually, this seems to already be the case. A netinstall is produced as a Fedora Server deliverable, but it can be used to install a non-Product system, and, if other Products adopted the same conventions, also any other Product. But does anyone own that netinstall working in this way? Not that I know of. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
- Original Message - On 25 Jul 2014, at 07:52, Phil Knirsch wrote: Summary: Mattdm then followed with 2 1/2 additional topics: 1a. Identifying different Fedora products -- fedora-release-* contents and /etc/os-release As I understand it, you are trying to decide where and how to set a flag that will signal the product that is either installed or to be installed. There was mention of dropping product specific snippets in /usr/lib/os-release.d/ as one solution. Does it have to be any more complex than the approach used by systemd? If fedora-release were to drop all product specific snippets in /usr/lib/os-release.d/, then a system admin could use a symbolic link in /etc/os-release.d to flag which product (or no product) he wanted installed. This alone is not sufficient because we need that information to be available as RPM dependencies ( https://fedoraproject.org/wiki/Per-Product_Configuration_Packaging_Draft ). So, in the end, we need the sysadmins to use rpm to switch between products. (This does not necessarily provide the _canonical_ answer for “how should other software check what product is installed”, but it does give us _a possible reliable_ answer—namely, “query the RPM database“). snip and then run whatever product syncing tool you develop -- perhaps: dnf product-sync What if the user changes the symlink but doesn‘t run the tool? We should be able to do this (if, indeed, we do need to support switching products at all) without requiring a two-step manual process. 2. a generic fedora netinstall I appreciate your continued consideration of this item. I'm not clear on how Anaconda is supposed to work with different products, but if it is reading whatever product flag you set in order to determine the package list, couldn't a single netinstall CD work for all products, as well as a generic, non-productized install, assuming that there were a place in the UI to specify which product the user wanted installed? Actually, this seems to already be the case. A netinstall is produced as a Fedora Server deliverable, but it can be used to install a non-Product system, and, if other Products adopted the same conventions, also any other Product. How this works: For Server, comps.xml defines server-product-environment (visible as a Fedora Server” base environment on the Anaconda’s Software Selection screen), which contains a server-product group, and this groups pulls in the fedora-release-server package, ultimately defining the product. On a DVD, we restrict the set of packages available to essentially offer only the Fedora Server, and this causes other parts of comps to be filtered out and invisible to the user. OTOH, the netinstall image loads the full comps.xml from the internet, so all other environments (including non-product environments like “Minimal” or “Xfce Desktop”) are available as choices for the user, and they do not pull in the fedora-release-server package. If other Products defined a $name-product-environment environment in comps.xml (which they currently don’t because they don’t need to, for the live image-based and partition-image-based installations), the other products would equally be visible when booting the Server Product netinstall image. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
Summary: - moben aka Benekdit Morbach presented some of his first results of builreq analysis and wrote a tool for that[1]. Will work with haraldh, vpavlin and others on related topics. - Talked with Michal Sekletar and accepted him as a WG member. His focus is docker and container technologies. - Vaclav Pavlin demonstrated the latest Fedora 20 based docker images, only 133MB in size[2] generated via a kickstart file[3] Lively discussion around docker, anaconda and rel-eng followed those docker focus topics. Mattdm then followed with 2 1/2 additional topics: 1a. Identifying different Fedora products -- fedora-release-* contents and /etc/os-release 1b. having tools like yum and dnf talk to mirror manager in a way which lets us count product installs 2. a generic fedora netinstall For 1a and 1b dgilmore, sgallagh and mattdm have already done a larger thread on fedora-devel ML to discuss the proper approach and solution. Several ideas already in place, just need to be implemented(tm). Some more discussions past that about 2. and related items (install trees vs. images etc). Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-11/fedora_base_design_working_group.2014-07-11-15.13.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-11/fedora_base_design_working_group.2014-07-11-15.13.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-11/fedora_base_design_working_group.2014-07-11-15.13.log.html [1] https://github.com/moben/buildreq-check [2] http://vpavlin.fedorapeople.org/fedora-base-image/ [3] http://vpavlin.fedorapeople.org/fedora-base-image/container-fedora-small-20.ks -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs
On 25 Jul 2014, at 07:52, Phil Knirsch wrote: Summary: Mattdm then followed with 2 1/2 additional topics: 1a. Identifying different Fedora products -- fedora-release-* contents and /etc/os-release As I understand it, you are trying to decide where and how to set a flag that will signal the product that is either installed or to be installed. There was mention of dropping product specific snippets in /usr/lib/os-release.d/ as one solution. Does it have to be any more complex than the approach used by systemd? If fedora-release were to drop all product specific snippets in /usr/lib/os-release.d/, then a system admin could use a symbolic link in /etc/os-release.d to flag which product (or no product) he wanted installed. Similar to: /etc/systemd/system/default.target - /lib/systemd/system/ graphical.target a system admin could set a symbolic link: /etc/os-release.d/product - /usr/lib/os-release.d/workstation.product Then, if a system admin wanted to change the box to a server, or to a non-productized box, he could simply change the symbolic link to: /etc/os-release.d/product - /usr/lib/os-release.d/server.product or /etc/os-release.d/product - /usr/lib/os-release.d/generic.product and then run whatever product syncing tool you develop -- perhaps: dnf product-sync 2. a generic fedora netinstall I appreciate your continued consideration of this item. I'm not clear on how Anaconda is supposed to work with different products, but if it is reading whatever product flag you set in order to determine the package list, couldn't a single netinstall CD work for all products, as well as a generic, non-productized install, assuming that there were a place in the UI to specify which product the user wanted installed? -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
