Default Groups, Default Packages, CD Sets and DVD Size

[Jesse Keating]

On Mon, 2008-08-11 at 17:40 +0200, Jeroen van Meeuwen wrote:
> However, the default installation requires all 7 CDs, because of how the 
> compose tools resolve dependencies (inclusive) during the compose of the 
> media, and pull in more then is minimally required to complete the 
> actual transaction of a default installation. The compose tools do so 
> for good reason:
> 
> - one cannot know what package is the user-preferred package for any 
> given required capability (eg. for fictive capability 'web-client', 
> there's firefox, iceweasel, elinks, wget, curl, emacs, emacs, emacs, 
> foo, bar and baz)
> 
> - one cannot predict on what installed system one is performing an 
> upgrade, and to be able to close the transaction certain considerations 
> must be met justifying the need for inclusive dependency resolving when 
> composing the media (set) or installation tree.
> 
> - it makes the released media apply to N+X use-cases where the package 
> set or transaction payload during the installation is controlled in a 
> more granular fashion then the selection dialogs allow (by means of a 
> kickstart package manifest maybe?), which I guess applies more to 
> businesses or advanced users using Fedora then it does to Joe Average users.
> 
> Basically what I'm saying is that the 2.88 GB is spread over more then 
> the minimal amount of discs it would fit on, since the complete package 
> payload when using inclusive dependency resolving grows to 3.66 GB, or 7 
> discs. So, the compose process spits out 7 discs, each of which contain 
> a part of the 2.88 GB sized RPM payload needed for a default installation.

I've been playing a bit in this area, and noticed that if I make one
small change to pkgorder, at least on i386, a default 'next next next'
install based on a compose done with the Fedora config and it only needs
the first 3 media.  This isn't bad really, given the growth of the
distro.

> 
> == Next Generation of Package Ordering ==
> 
> So, what package ordering is going to do -instead of having a static 
> list of groups to add to a transaction, resolve, spit out the packages- 
> is use the "default" parameter to groups in comps.xml as well (and then 
> instead of exclusive dependency resolving like it does now, move to 
> inclusive dependency resolving as well). This makes the "which packages 
> and groups are in a default installation" a little less hard to maintain 
> and the package ordering will almost automagically match up with 
> comps.xml (of which the installation procedure also uses the default 
> parameter to groups!)

Hrm, I hadn't thought about applying inclusive depsolving (or
depresolving as I call it) here.  That could have some interesting
effects and warrants some investigation.

> 
> == DVD and Sizes ==
> 
> This leads me to another concern which may or may not be an immediate 
> issue but requires attention from those in the decision making chain as 
> well as generally interested people; the size of the DVD ISO is getting 
> to it's maximum allowed size (just under 4GB for those who use FAT 
> systems as their downloaded data partition), providing just a default 
> (eg. not including anything in addition to the default).

It's worse than that.  We overflowed the DVD size on PPC, and as such we
added a set of excludes to the manifest so that we would fit again.

> == Advise needed ==
> 
> There's several ways this can be solved, but I'm not sure what is the 
> most advisable (some are not feasible I'm sure, I'm just brainstorming 
> here):
> 
> 1) reduce the number of mandatory and default packages per group in 
> comps.xml

This is a great start, something that hasn't really been done outside of
core/base recently that I'm aware of.

> 
> 2) reduce the number of groups in comps.xml that have "default" set to True

This one is going to be a bit tougher to get people to agree upon I'd
imagine, but I'm willing to give it a go.

> 
> 3) Revisit how comps is formatted; Example: Keep the "default" for 
> compose decisions, but add an "install" attribute for installation 
> decision making. Install set to True may require default set to True as 
> well for the group to even be included on the media.

What exactly does this accomplish?

> 
> 4) Split the packages that are mandatory or default in comps groups, 
> into smaller packages providing what the group needs and another set of 
> smaller packages belonging to the group as to reduce the number of 
> dependencies needing to be met when the compose or installation 
> procedure selects a group. See also PS2.
> 
> 5) Or, compared to 4, revisit the Requires in mandatory and default 
> packages and the Provides in the packages that provide the required 
> capabilities so that it abstracts from the requires/provides matching 
> with too many other packages (related to the inclusive dependency 
> resolving which will then make for a thinner RPM payload on the composed 
> media)

This is probably a more interesting case, something that we want to do
for folks like OLPC as well.

> 
> 6) Have the compose tools as well as the installation procedures not 
> depend on the default attribute to groups anymore, at all.

What does this accomplish?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080812/4ee2c2c3/attachment.sig>