Dropping a lot of files from the DVD

Stephen Gallagher sgallagh at redhat.com
Mon Aug 10 19:29:28 UTC 2015


On Mon, 2015-08-10 at 15:19 -0400, Simo Sorce wrote:
> On Mon, 2015-08-10 at 14:46 -0400, Stephen Gallagher wrote:
> > During the F23 Alpha release process, we hit upon a bug[1] in 
> > FreeIPA
> > (actually tomcatjss) that prevented the Domain Controller 
> > deployment
> > from working (or FreeIPA from being installed at all). We were able 
> > to
> > handwave this at Alpha by observing that almost no one actually
> > installs the packages from the DVD and rolekit defaults to updating
> > from the network anyway. So we were able to fix this for Alpha 
> > without
> > necessitating a respin of the media (and causing a slip of the
> > release).
> > 
> > We also had another bug[2] that caused compose issues which was 
> > related
> > to a FTBFS with the perl-MongoDB package.
> > 
> > It got several of us thinking, however. Why are we shipping much
> > (most?) of the stuff we have on the DVD? I can understand some of 
> > the
> > choices we've made, like shipping support packages for uncommon 
> > (but
> > not unheard-of) hardware as optional installs, but why are we 
> > shipping
> > the "perl-web" group? Or PHP? Do we really need the load-balancer 
> > and
> > high-availability groups right there on the disk?
> > 
> > I'd like to propose that we drop from the Server installation
> > everything that is not either part of the default install as it now
> > stands or an optional component for hardware support.
> > 
> > This would mean that we could remove a lot of historical cruft; all 
> > of
> > the things we are dropping would remain available post-install or 
> > via a
> > network install. They would simply stop being available from a DVD
> > install.
> > 
> > There's a new feature[3] of rolekit that I have been working on 
> > that
> > will allow us to deploy roles as part of kickstart, but it does not
> > require that the packages actually be on the DVD at all; it only
> > requires that the system have a valid network connection upon 
> > booting
> > up for the first time. The way it will work is by creating a 
> > systemd
> > service unit during the kickstart %post that will fire once the 
> > network
> > is up on the newly-booted system and then will proceed to pull the
> > packages from the appropriate repositories and start the roles.
> > 
> > Going this route would significantly reduce the size of the DVD as 
> > well
> > as the risk that issues in one of our supported roles would block 
> > the
> > release. (They would still need to be fixed and pushed stable for 0
> > -day, but they wouldn't necessitate a respin of the media and thus 
> > a
> > new validation run).
> > 
> > If we approve this plan, we'll probably need to amend the release
> > criteria to accommodate it.
> > 
> > Thoughts? I'd like to put this plan in place well in advance of 
> > Beta so
> > that we can validate it with early test composes (and not risk
> > slippage).
> 
> So the DVD just become a netinstall++ ?

Well, no. The DVD would essentially become "Here's the stuff we think
you need" rather than "Here's all the stuff somebody might ever need".

That's different from the netinstall, which really can install anything
and everything that exists in the repositories.


> 
> I am not against it, just want to understand what will be left back.
> Will there be packages enough to have a GUI for example ? Or will 
> they
> all be "available from the network" ?
> 

Well, we don't have a GUI now, excepting Cockpit (which would
absolutely remain part of the default set included on the DVD). If you
want a GUI, you need to install it from the network, either by using
the netinstall media, adding the Everything repo in Anaconda or else
adding the GUI packages post-install.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150810/7f85511c/attachment.sig>


More information about the server mailing list