fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
sgallagh at redhat.com
Thu Jul 10 14:34:01 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 07/10/2014 09:53 AM, Mike Pinkerton wrote:
> On 10 Jul 2014, at 07:04, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> On 07/09/2014 05:08 PM, Matthew Miller wrote:
>>> On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher
>>>> I do not know which or if any Spins will be providing the
>>>> specific net install CD you're asking about. This will not be
>>>> an *official* (read: tested by QA) method of installing
>>>> Fedora. However, I see no reason why it wouldn't work.
>>> A few months ago* I remember the server WG talking about
>>> providing a minimal/netinstall image. Has this changed?
>>> * dredges up meeting logs --
That's why I said the *specific* netinstall he was asking for. The
>> Fedora Server netinstall wouldn't be producing a non-productized
>> result, which is what he asked for: "4. There would be, at
>> least, a net install CD to install a traditional
>> "non-productized" Fedora system."
> A minimal netinstall would be ok if there is a simple way to
> replace the "productized" fedora-release package with a plain,
> non-productized fedora-release package.
> In saying that, I am making an assumption that, once the
> fedora-release package is switched out, then any "product"
> requirements or constraints would disappear and the system would be
> a traditional, non-productized Fedora system that could then be
> configured however the system administrator chose.
> Is that assumption wrong?
That is the intent of the design, yes. We're dealing with some
real-world issues with that (namely that the way dependency-processing
works in yum and dnf has issues with this), so it may require us to
code up a special tool to switch from productized to non-productized
Stop reading now if you don't care about minutia:
Basically, in order to swap out the productized and non-productized
release packages, it's not actually as simple as 'yum swap
fedora-release-standard fedora-release-server'. The way the dependency
processing works in yum and dnf will generally fall over and fail to
properly detect the other packages that would need to be swapped (such
as firewalld-config-standard -> firewalld-config-server). So what we
will probably need to do is write a tool that will examine the RPM
database for all product-specific packages and swap them in a single
transaction. This is hard to do *generically*, but if everyone sticks
with the convention mandated by my proposed Draft, it becomes a
pattern-match instead of a deep dependency comparison (which is
probably "good enough" for the first pass).
There's also a significant hope that future RPM enhancements (with
complex and powerful deps like "if foo is installed, then install
bar") will allow us to make this a much more simple process.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the devel