[Yum-devel] Forwarding on a Fedora discussion - Packaging & installation

Bill Nottingham notting at redhat.com
Fri Mar 2 19:13:35 UTC 2012


Forwarding this along, as we may need yum changes for what's being proposed
here. See the questions at the end, especially.

Bill

----- Forwarded message from Bill Nottingham <notting at redhat.com> -----

Date: Fri, 24 Feb 2012 16:55:34 -0500
From: Bill Nottingham <notting at redhat.com>
To: anaconda-devel-list at redhat.com
Cc: spins at lists.fedoraproject.org
Subject: Packaging & installation
User-Agent: Mutt/1.5.21 (2010-09-15)

Prompted by David Lehman's patch set, I wanted to discuss how we're
building what we're installing in Fedora and RHEL, and how we might need to
represent that both in the media and in the UI.

What we've got now exposed at the lowest level (yum/kickstart) and supported
as first-level objects throughout the system:
1. packages
2. groups (of packages)
3. repos (which contain group lists, and packages)

What we additionally expose only in anaconda, and lose post-install:
4. tasks in install classes (lists of groups)

What we expose in Fedora:
5. spins (live ISO via kickstart file)
6. 'the install DVD' (a package set via a kickstart file)

What we expose in RHEL:
7. variants (essentially, a spin that's a package set instead of a live ISO)
8. add-ons (repos, with groups, that apply to specific variants)

All of these use the comps file, which is a list of groups.

Now, as we rework anaconda's UI (and backend, per dlehman's patches), we
need to make sure not to break everything horribly.

In Fedora, spins and the install DVD are driven off of kickstart files. This
was done because it's the only thing pungi and livecd-creator supports, and
because each spin/install DVD is a distinct object that can have its own
kickstart. Anaconda doesn't need to worry about separately consuming them,
as there's only one repo to ever pull from, and the spins are live images.

In RHEL, variants and add-ons are driven off of a different set of files,
for assorted historical reasons. Kickstart files don't directly work here
because they don't allow you to define intermediate objects (add-ons) that
are presented in the installer. Anaconda processes variants and add-ons via
code that reads .treeinfo.

PROPOSAL GIVEN THE NEW UI

For reference, the proposed new UI is at:
	http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Live%20Prototypes/07-software.svg

As you'll notice, it contains something that looks like a spin or variant on
the left, and things that could be considered 'add-ons' on the right. These
apply to the choices on the left.

This would seem to fit nicely into the variants + add-ons model that RHEL
uses. However, there are a couple of problems:

- The code that parses the variants/add-on information and creates the
  appropriate .treeinfo bits does not exist in Fedora

This is obviously a simple matter of not-so-simple code.

- It requires creating a separate set of metadata (the variants file) that
  does not currently exist.

This is relatively trivial.

- It can cause skew between the live and not-live spins if this variants file
  falls out of sync with the kickstarts in spin-kickstarts.

This is ugly - how can we get these to use a single set of data?
Unfortunately, kickstart's %packages model doesn't give us an easy way to
define a variant and its add-ons in a kickstart file. Ideas?

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

----- End forwarded message -----
----- Forwarded message from Martin Sivak <msivak at redhat.com> -----

Date: Mon, 27 Feb 2012 03:59:46 -0500 (EST)
From: Martin Sivak <msivak at redhat.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer
	<anaconda-devel-list at redhat.com>
Subject: Re: Packaging & installation

Hi,

regarding variants/addons:

My idea for some time now has been to include something in the main repository, either as metadata structure or a package with specific name.

That container could then hold (an example) multiple named kickstarts representing variants and that kickstart could specify subrepositories representing addons (%repo --addon="name"?).

We could also create kickstarts/shell scripts named after previous versions/releases which would be able to do the single shot upgrade tasks (the same stuff we face now with usrmove in f17) from the release they represent.

Having this in repo would allow us to integrate it to multiple places like anaconda itself, preupgrade, ....

Those data could of course also be created as part of comps (so we have translations) or in the form of package dependencies (one super spin package which will bring all spin packages in and does pre/post install changes).

Martin

----- Original Message -----
> Prompted by David Lehman's patch set, I wanted to discuss how we're
> building what we're installing in Fedora and RHEL, and how we might
> need to
> represent that both in the media and in the UI.
> 
> What we've got now exposed at the lowest level (yum/kickstart) and
> supported
> as first-level objects throughout the system:
> 1. packages
> 2. groups (of packages)
> 3. repos (which contain group lists, and packages)
> 
> What we additionally expose only in anaconda, and lose post-install:
> 4. tasks in install classes (lists of groups)
> 
> What we expose in Fedora:
> 5. spins (live ISO via kickstart file)
> 6. 'the install DVD' (a package set via a kickstart file)
> 
> What we expose in RHEL:
> 7. variants (essentially, a spin that's a package set instead of a
> live ISO)
> 8. add-ons (repos, with groups, that apply to specific variants)
> 
> All of these use the comps file, which is a list of groups.
> 
> Now, as we rework anaconda's UI (and backend, per dlehman's patches),
> we
> need to make sure not to break everything horribly.
> 
> In Fedora, spins and the install DVD are driven off of kickstart
> files. This
> was done because it's the only thing pungi and livecd-creator
> supports, and
> because each spin/install DVD is a distinct object that can have its
> own
> kickstart. Anaconda doesn't need to worry about separately consuming
> them,
> as there's only one repo to ever pull from, and the spins are live
> images.
> 
> In RHEL, variants and add-ons are driven off of a different set of
> files,
> for assorted historical reasons. Kickstart files don't directly work
> here
> because they don't allow you to define intermediate objects (add-ons)
> that
> are presented in the installer. Anaconda processes variants and
> add-ons via
> code that reads .treeinfo.
> 
> PROPOSAL GIVEN THE NEW UI
> 
> For reference, the proposed new UI is at:
> 	http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Live%20Prototypes/07-software.svg
> 
> As you'll notice, it contains something that looks like a spin or
> variant on
> the left, and things that could be considered 'add-ons' on the right.
> These
> apply to the choices on the left.
> 
> This would seem to fit nicely into the variants + add-ons model that
> RHEL
> uses. However, there are a couple of problems:
> 
> - The code that parses the variants/add-on information and creates
> the
>   appropriate .treeinfo bits does not exist in Fedora
> 
> This is obviously a simple matter of not-so-simple code.
> 
> - It requires creating a separate set of metadata (the variants file)
> that
>   does not currently exist.
> 
> This is relatively trivial.
> 
> - It can cause skew between the live and not-live spins if this
> variants file
>   falls out of sync with the kickstarts in spin-kickstarts.
> 
> This is ugly - how can we get these to use a single set of data?
> Unfortunately, kickstart's %packages model doesn't give us an easy
> way to
> define a variant and its add-ons in a kickstart file. Ideas?
> 
> Bill
> 
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
> 

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

----- End forwarded message -----
----- Forwarded message from David Lehman <dlehman at redhat.com> -----

Date: Fri, 02 Mar 2012 12:00:20 -0600
From: David Lehman <dlehman at redhat.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer
	<anaconda-devel-list at redhat.com>
Cc: spins at lists.fedoraproject.org
Subject: Re: Packaging & installation

On Fri, 2012-02-24 at 16:55 -0500, Bill Nottingham wrote:
> Prompted by David Lehman's patch set, I wanted to discuss how we're
> building what we're installing in Fedora and RHEL, and how we might need to
> represent that both in the media and in the UI.
> 
> What we've got now exposed at the lowest level (yum/kickstart) and supported
> as first-level objects throughout the system:
> 1. packages
> 2. groups (of packages)
> 3. repos (which contain group lists, and packages)
> 
> What we additionally expose only in anaconda, and lose post-install:
> 4. tasks in install classes (lists of groups)

This should go away, whatever else we do.

> 
> What we expose in Fedora:
> 5. spins (live ISO via kickstart file)
> 6. 'the install DVD' (a package set via a kickstart file)
> 
> What we expose in RHEL:
> 7. variants (essentially, a spin that's a package set instead of a live ISO)
> 8. add-ons (repos, with groups, that apply to specific variants)
> 
> All of these use the comps file, which is a list of groups.
> 
> Now, as we rework anaconda's UI (and backend, per dlehman's patches), we
> need to make sure not to break everything horribly.
> 
> In Fedora, spins and the install DVD are driven off of kickstart files. This
> was done because it's the only thing pungi and livecd-creator supports, and
> because each spin/install DVD is a distinct object that can have its own
> kickstart. Anaconda doesn't need to worry about separately consuming them,
> as there's only one repo to ever pull from, and the spins are live images.
> 
> In RHEL, variants and add-ons are driven off of a different set of files,
> for assorted historical reasons. Kickstart files don't directly work here
> because they don't allow you to define intermediate objects (add-ons) that
> are presented in the installer. Anaconda processes variants and add-ons via
> code that reads .treeinfo.
> 
> PROPOSAL GIVEN THE NEW UI
> 
> For reference, the proposed new UI is at:
> 	http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Live%20Prototypes/07-software.svg
> 
> As you'll notice, it contains something that looks like a spin or variant on
> the left, and things that could be considered 'add-ons' on the right. These
> apply to the choices on the left.
> 
> This would seem to fit nicely into the variants + add-ons model that RHEL
> uses. However, there are a couple of problems:
> 
> - The code that parses the variants/add-on information and creates the
>   appropriate .treeinfo bits does not exist in Fedora
> 
> This is obviously a simple matter of not-so-simple code.
> 
> - It requires creating a separate set of metadata (the variants file) that
>   does not currently exist.
> 
> This is relatively trivial.
> 
> - It can cause skew between the live and not-live spins if this variants file
>   falls out of sync with the kickstarts in spin-kickstarts.
> 
> This is ugly - how can we get these to use a single set of data?
> Unfortunately, kickstart's %packages model doesn't give us an easy way to
> define a variant and its add-ons in a kickstart file. Ideas?

In theory, what we need is two new meta-group types: variant (aka spin)
and addon. Each is a set of groups. You can only have one variant
selected or installed at any given time. Each variant defines a set of
addons, of which any number may be selected/installed. Regular groups
and packages are only exposed via kickstart, if at all.

Once we have the groups set up and accompanying kickstart support, the
spins should end up being exactly the same package set as you'd get by
choosing the same variant+addons in the anaconda software selection ui.
The addition of meta-packages and/or kickstart script snippets (perhaps
per variant?) could bridge the gap so that the spins end up identical to
the corresponding anaconda variant/addon selections.

How does this fit with your proposal and your concerns?

Dave

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

----- End forwarded message -----
----- Forwarded message from Bill Nottingham <notting at redhat.com> -----

Date: Fri, 2 Mar 2012 14:02:15 -0500
From: Bill Nottingham <notting at redhat.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer
	<anaconda-devel-list at redhat.com>
Cc: spins at lists.fedoraproject.org
Subject: Re: Packaging & installation
User-Agent: Mutt/1.5.21 (2010-09-15)

David Lehman (dlehman at redhat.com) said: 
> In theory, what we need is two new meta-group types: variant (aka spin)
> and addon. Each is a set of groups. You can only have one variant
> selected or installed at any given time. Each variant defines a set of
> addons, of which any number may be selected/installed. Regular groups
> and packages are only exposed via kickstart, if at all.
> 
> Once we have the groups set up and accompanying kickstart support, the
> spins should end up being exactly the same package set as you'd get by
> choosing the same variant+addons in the anaconda software selection ui.
> The addition of meta-packages and/or kickstart script snippets (perhaps
> per variant?) could bridge the gap so that the spins end up identical to
> the corresponding anaconda variant/addon selections.
> 
> How does this fit with your proposal and your concerns?

I can see this working. Initial concerns:

- Would we need to drive the variants and add-ons into first class objects
  in yum as well (such that, if intstalled, they're marked on the system in
  some way (yumdb, etc.), and that they can be installed post-install, etc?)
  The simplest solution is add these as additional sections in the comps file,
  and parse them with yum's comps module - the question is whether this info
  is used in yum itself outside of that, or if it's left for higher-level tools.

- In RHEL, due to fun with entitlements & certs, add-ons are segmented as
  separate repos. Your proposal doesn't obviously prevent this, but I think
  we need to explicitly keep that working.

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

----- End forwarded message -----


More information about the Yum-devel mailing list