Fedora.next in 2014 -- Big Picture and Themes

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2014 06:12 PM, Lars Seipel wrote:
> On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote:
>> Also possibly correct.  However, that doesn't preclude the repos
>> as we know them today from still existing, with still the same
>> quality.
> 
> Server, desktop or embedded board, in today's Fedora it's all the
> same, just with a different package set installed. People (not all,
> obviously) consider this a good thing. I just have to put a minimal
> Fedora install on some machine and then build it from there.
> 
> That's what Tom was getting at, I think. The discussions in the WGs
> so far have hinted that it's not necessarily a reasonable
> expectation that this will continue to be the case. An oft-cited
> reason was that RPMs apparently can't provide the 'integration'
> that is somehow wanted.
> 
> I always considered it nice that there's only a single Fedora. I
> thought that split products were mostly an artefact of commercial 
> differentiation and so Fedora users don't have to deal with "you
> can't use this filesystem unless you have the Ultra Enterprise
> Storage Edition" or stuff like that. ☺
> 


I agree with you. My stated (and oft-repeated) position in the Server
WG is that the available package sets should not diverge between the
Products so far as is feasible.

What I'd like to see is mainly that we allow a limited set of
intentionally-conflicting packages in the repository that allow us to
provide different default configurations for the products. So for any
package that has a configuration that might want different defaults
for Server vs. Workstation, we would have it produce two sub-packages,
one for each sensible default.

To take the DHCP example elsewhere in the thread, we could have:
dhcp-config-default-on
  Provides: dhcp-config
  Conflicts: dhcp-config-default-off

dhcp-config-default-off
  Provides: dhcp-config
  Conflicts: dhcp-config-default-on


The dhcp package would Requires: dhcp-config (and therefore not care
which one it gets). Then we would have a release package for Fedora
Server and Fedora workstation that would specifically Requires: the
appropriate one (so that when yum/dnf resolution occurs, the right one
gets selected).

e.g.
fedora-release-server-21
  Requires: dhcp-config-default-off

fedora-release-workstation-21
  Requires: dhcp-config-default-on



On a related note, I'd also strongly like to recommend that we start
using the fedora-release-*-VERSION packages as meta-packages that
contain strict Requires: defining a minimum set of packages necessary
to qualify as "Fedora Server", "Fedora Cloud" or "Fedora Workstation".

So for example in the Fedora Server, this might be the minimum set of
packages necessary to have a system with SSHD and the infrastructure
to deploy Fedora Server Roles. On Fedora Workstation, perhaps it
defines the set of packages conforming to GnomeOS 3.14.

The idea would be that you'd still have the option to reduce the set
of packages on the system, but at that point you would be voluntarily
exiting the set of tested functionality. (And this would be checkable
with a simple 'rpm -q' call)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLit/0ACgkQeiVVYja6o6ONGgCghQXjNgPDx7y0s482LpSSTBHz
vrYAn3YjuqAlh+jwi+08OqYsZL/k0B2G
=6pJp
-----END PGP SIGNATURE-----