Re: fc5 goals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthew Miller (mattdm@xxxxxxxxxx) said: 
> On Tue, Nov 29, 2005 at 08:50:27PM +0100, Arjan van de Ven wrote:
> > there's an alternative...
> > there could be a cd split such that OOo and related all ends up on one
> > cd, and the installer/firstboot adjusted in a way that it can take such 
> > "application CDs".
> > Heck maybe gnome and kde could be such cd's as well over time.
> 
> I'm very much for that. In my mind, everything not on the "main" CD would be
> Extras, but if people prefer for some of these extra sets to be Core still,
> that's cool too.

Here's something I wrote briefly to explain how some of this *could*
be done. Alas, no time to implement.

Bill

...



Rewrite splitdistro, pkgorder to let you do more fun things
-----------------------------------------------------------

First, you extend comps.

  Each group can have an optional <discid> tag. Multiple groups
  can share a <discid>. No discid for a group makes it 'Base',
  or 'Core', or whatever you want to call it.

  Later in the comps file you have <dischierarchy>, which
  denotes an order for the <discid> tags. (Alternatively, define
  discids to be numbers, and sort that way.) Order such that
  any obvious dependencies between groups are resolved;, i.e.,
  discids are listed below any discids they have deps on.
  
  <discids> are linked to an English string that is the title
  of the group, used in naming the CDs, and put in the discinfo
  file for the CD. It's intltool-ized and all that other good stuff,
  for display in $(YOUR PACKAGE GRABBING TOOL HERE).

Then, you redo how packages are ordered.

  Look at the universe of packages in your tree. Arrange them
  into the following groups based on comps:
  
  A: Packages listed in a comp that doesn't have a discid
  B: Packages listed in comps that have the first discid in the
     dischierarchy
  C: Packages listed in cimps that have the second discid ...
  ...
  #: Packages not in any comp.
  
  Structure things so that A, B, C, etc could be completely separate
  repos from your CD-creation set. For example, A could be Core,
  and B,C,D, etc are all things in Extras.
  
  Depsolve A against B,C, ... and #; move packages from other buckets
  to A to solve deps. If any deps are from B,C, ..., raise warning.
  
  Depsolve B, against A and #, move packages to solve deps. If any deps
  are unresolved, raise a hard error.
  
  Depsolve C, against A, B, and #, ...
  
  Throw everything else from # into A.
  
  Generate pkgorder for A.
  
  Generate pkgorder for B, as an additional transaction on top of A.
  
  Generate pkgorder for C, as an additional transaction on top of A and B.
  
  ...
  
  Split trees based on their separate pkgorders. Optionally, track in
  the pkgorders which packages are added to B, C, D, etc from #; if B,
  C, D... are sllightly over X discs, move those packages to A and
  recompute.

  Label CDs based on A with the standard "Name, Disc 1 ... X". Label
  CDs based on B, C, D... with the discid's name, and discs 1 ... X.
  
  Hence, now anaconda would display:
  
     To complete the install, you need:
     
        Fedora Core 5 disc #1
	Fedora Core 5 disc #2
	Fedora Office disc #1
	Fedora Java disc #1
	

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux