RPM Weak Dependencies and the install media compose process

[Stephen Gallagher]

(Please keep the conversation on the devel list; I'm CCing it the rel
-eng list to make sure all the relevant people see the initial message)

This past week, the Fedora Packaging Committee approved the use of
"weak dependencies" in Fedora. What this means is that RPM packages can
now have three levels of dependency-resolution: Requires, Recommends
and Suggests.
 * Requires: the requested package cannot function without this
additional package installed
 * Recommends: the requested package can function in some minimal
capacity without this additional package installed, but the majority of
installations will want it for full productivity. These are usually
core plugins for the primary package. DNF defaults to installing
Recommends: dependencies automatically.
 * Suggests: the requested package can easily function without this
additional package. This module may provide some less-common
functionality that a user might want. DNF defaults to *not* installing
Suggests: packages automatically.

Traditionally, we have only supported "Requires" dependencies and thus
the creation of install media (Live and otherwise) has been relatively
straightforward: we create a kickstart file that is fed into the
compose process containing a list of packages and groups that we want
installed onto the target system and the compose process automatically
pulls in all of the dependencies. However, with the advent of weak
dependencies, we have new questions that need answering about how this
compose process should work. (We also need to investigate what exactly
happens with the tools we have today - some of which still use yum, not
DNF - when weak dependencies are added to the mix).

From my perspective, there are three ways that we could choose to go:

1) Follow the default DNF behavior: Requires: and Recommends: packages
are included on the install media (and therefore also installed
together onto the target system)

2) Include *all* dependencies - Requires, Recommends and Suggests - on
the install media. The installer would still follow DNF defaults, so
the target system would get only the Requires and Recommends packages
unless the Suggests: packages are explicitly selected (which will also
require the creation of additional comps.xml changes to include the
Suggests packages)

3) Include only Requires: dependencies by default and require spin
-kickstarts owners to explicitly add any Recommends or Suggests
packages that they also want to include. Packages added explicitly will
be installed as described in 2) (requiring additional comps.xml changes
to include Suggests stuff)


Note that at the moment, DNF itself does not have a configuration
option to tweak the default install behavior, so 'dnf install'
effectively treats Recommends the same way as Requires (but 'dnf
remove' will treat them differently, of course). I discussed this with
the DNF developers this morning and they hope to have a configuration
option and/or command-line argument available to change this behavior
before Beta Freeze, so we should still be able to ship F23 with any of
the above options.

I think the best time to make these decisions is now, well in advance
of the Alpha Freeze so we have time to make adjustments as needed.
Thank you for reading to the end, I know the above has been a wall-o'
-text.

[Josh Boyer]

On Fri, Jul 10, 2015 at 8:05 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  (Please keep the conversation on the devel list; I'm CCing it the
> rel
>  -eng list to make sure all the relevant people see the initial message)
>
>  This past week, the Fedora Packaging Committee approved the use of
>  "weak dependencies" in Fedora. What this means is that RPM packages can
>  now have three levels of dependency-resolution: Requires, Recommends
>  and Suggests.
>   * Requires: the requested package cannot function without this
>  additional package installed
>   * Recommends: the requested package can function in some minimal
>  capacity without this additional package installed, but the majority of
>  installations will want it for full productivity. These are usually
>  core plugins for the primary package. DNF defaults to installing
>  Recommends: dependencies automatically.
>   * Suggests: the requested package can easily function without this
>  additional package. This module may provide some less-common
>  functionality that a user might want. DNF defaults to *not* installing
>  Suggests: packages automatically.
>
>  Traditionally, we have only supported "Requires" dependencies and thus
>  the creation of install media (Live and otherwise) has been relatively
>  straightforward: we create a kickstart file that is fed into the
>  compose process containing a list of packages and groups that we want
>  installed onto the target system and the compose process automatically
>  pulls in all of the dependencies. However, with the advent of weak
>  dependencies, we have new questions that need answering about how this
>  compose process should work. (We also need to investigate what exactly
>  happens with the tools we have today - some of which still use yum, not
>  DNF - when weak dependencies are added to the mix).
>
>  From my perspective, there are three ways that we could choose to go:
>
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system)
>
>  2) Include *all* dependencies - Requires, Recommends and Suggests - on
>  the install media. The installer would still follow DNF defaults, so
>  the target system would get only the Requires and Recommends packages
>  unless the Suggests: packages are explicitly selected (which will also
>  require the creation of additional comps.xml changes to include the
>  Suggests packages)
>
>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff) 
You didn't offer your opinion on which of the three options you think
we should go with.  I would offer option 1 is the one we'd pick.  It
honors the intentions of the package maintainer the best.  Which would
you choose?

josh

[Michael Catanzaro]

On Fri, 2015-07-10 at 08:20 -0400, Josh Boyer wrote:
>  You didn't offer your opinion on which of the three options you
> think
>  we should go with.  I would offer option 1 is the one we'd pick.  It
>  honors the intentions of the package maintainer the best.  Which 
>  would
>  you choose? 
Option 2 is just weird. If a packager uses Suggests to express a
dependency, that means the dependency should not be installed
automatically. If packagers have to think "is my package installed by
default and if so would it be bad to have this Suggested package
installed as well," that's going to make Suggests much less useful.

Option 3 would increase the need to manually add missing packages that
we actually want. For instance, we currently have evince-browser-plugin
listed in comps for Workstation as a workaround for not being able to
use Recommends in Evince's spec. If we go with Option 3, we'll need to
keep it there forever. If a package shouldn't be installed by default
with another package, then Recommends should not have been used!

I think Option 1 is the best, so that package maintainers don't have to
think separately about the difference between install media compose and
normal package installation..

[Stephen Gallagher]

On Fri, 2015-07-10 at 07:56 -0500, Michael Catanzaro wrote:
>  On Fri, 2015-07-10 at 08:20 -0400, Josh Boyer wrote:
>  > You didn't offer your opinion on which of the three options you 
>  > think
>  > we should go with.  I would offer option 1 is the one we'd pick. 
>  >  It
>  > honors the intentions of the package maintainer the best.  Which 
>  > would
>  > you choose?
>  
>  Option 2 is just weird. If a packager uses Suggests to express a
>  dependency, that means the dependency should not be installed
>  automatically. If packagers have to think "is my package installed by
>  default and if so would it be bad to have this Suggested package
>  installed as well," that's going to make Suggests much less useful.
>   
These options describe what packages are on the install media, *not*
necessarily what is installed on the target system. (Though in the case
of Live media, I suppose the difference is academic). In any case, I
agree that this is a poor option and mostly included it for
completeness.


>  Option 3 would increase the need to manually add missing packages 
>  that
>  we actually want. For instance, we currently have evince-browser
>  -plugin
>  listed in comps for Workstation as a workaround for not being able to
>  use Recommends in Evince's spec. If we go with Option 3, we'll need 
>  to
>  keep it there forever. If a package shouldn't be installed by default
>  with another package, then Recommends should not have been used!
>  
>  I think Option 1 is the best, so that package maintainers don't have 
>  to
>  think separately about the difference between install media compose 
>  and
>  normal package installation.. 

Yeah, there's definite value to avoiding overcomplication, I suppose.

Perhaps Option 1) is a good solution as long as we test and verify that
specifying
-recommendedpackage
in the kickstart file removes it properly (for cases where we want to
explicitly trim down size).

One thing that's been proposed in the past was to have documentation
moved into a Recommends: subpackage that we could then remove from
embedded or minimalistic installs. So I want to be able to keep that as
an option.

[Stephen Gallagher]

On Fri, 2015-07-10 at 08:20 -0400, Josh Boyer wrote:
>  On Fri, Jul 10, 2015 at 8:05 AM, Stephen Gallagher <
>  sgallagh(a)redhat.com&gt; wrote:
>  > (Please keep the conversation on the devel list; I'm CCing it the 
>  > rel
>  > -eng list to make sure all the relevant people see the initial 
>  > message)
>  > 
>  > This past week, the Fedora Packaging Committee approved the use of
>  > "weak dependencies" in Fedora. What this means is that RPM packages 
>  > can
>  > now have three levels of dependency-resolution: Requires, 
>  > Recommends
>  > and Suggests.
>  >  * Requires: the requested package cannot function without this
>  > additional package installed
>  >  * Recommends: the requested package can function in some minimal
>  > capacity without this additional package installed, but the 
>  > majority of
>  > installations will want it for full productivity. These are usually
>  > core plugins for the primary package. DNF defaults to installing
>  > Recommends: dependencies automatically.
>  >  * Suggests: the requested package can easily function without this
>  > additional package. This module may provide some less-common
>  > functionality that a user might want. DNF defaults to *not* 
>  > installing
>  > Suggests: packages automatically.
>  > 
>  > Traditionally, we have only supported "Requires" dependencies and 
>  > thus
>  > the creation of install media (Live and otherwise) has been 
>  > relatively
>  > straightforward: we create a kickstart file that is fed into the
>  > compose process containing a list of packages and groups that we 
>  > want
>  > installed onto the target system and the compose process 
>  > automatically
>  > pulls in all of the dependencies. However, with the advent of weak
>  > dependencies, we have new questions that need answering about how 
>  > this
>  > compose process should work. (We also need to investigate what 
>  > exactly
>  > happens with the tools we have today - some of which still use yum, 
>  > not
>  > DNF - when weak dependencies are added to the mix).
>  > 
>  > From my perspective, there are three ways that we could choose to 
>  > go:
>  > 
>  > 1) Follow the default DNF behavior: Requires: and Recommends: 
>  > packages
>  > are included on the install media (and therefore also installed
>  > together onto the target system)
>  > 
>  > 2) Include *all* dependencies - Requires, Recommends and Suggests - 
>  > on
>  > the install media. The installer would still follow DNF defaults, 
>  > so
>  > the target system would get only the Requires and Recommends 
>  > packages
>  > unless the Suggests: packages are explicitly selected (which will 
>  > also
>  > require the creation of additional comps.xml changes to include the
>  > Suggests packages)
>  > 
>  > 3) Include only Requires: dependencies by default and require spin
>  > -kickstarts owners to explicitly add any Recommends or Suggests
>  > packages that they also want to include. Packages added explicitly 
>  > will
>  > be installed as described in 2) (requiring additional comps.xml 
>  > changes
>  > to include Suggests stuff)
>  
>  You didn't offer your opinion on which of the three options you think
>  we should go with.  I would offer option 1 is the one we'd pick.  It
>  honors the intentions of the package maintainer the best.  Which 
>  would
>  you choose?
>   

Honestly, I'm torn between options 1) and 2). On the one hand, option 1
most closely matches what would happen if you installed the same set of
packages on a post-installed system. On the other hand, it means that
we're putting a lot of content on the install media that might be
*desirable* but isn't strictly *required*. Saving space on the download
isn't always a bad thing. Also, certain spins may have valid reasons to
keep certain packages off for space concerns (or they are intended for
certain hardware, etc.)

The only thing I'll say definitely is that option 2) is not terribly
useful, since the same effect can be accomplished by option 1) or 3)
and just adding extra packages explicitly in the kickstart.

[Dennis Gilmore]

On Friday, July 10, 2015 08:05:24 AM Stephen Gallagher wrote:
>  (Please keep the conversation on the devel list; I'm CCing it the
> rel
>  -eng list to make sure all the relevant people see the initial message)
>  
>  This past week, the Fedora Packaging Committee approved the use of
>  "weak dependencies" in Fedora. What this means is that RPM packages can
>  now have three levels of dependency-resolution: Requires, Recommends
>  and Suggests.
>   * Requires: the requested package cannot function without this
>  additional package installed
>   * Recommends: the requested package can function in some minimal
>  capacity without this additional package installed, but the majority of
>  installations will want it for full productivity. These are usually
>  core plugins for the primary package. DNF defaults to installing
>  Recommends: dependencies automatically.
>   * Suggests: the requested package can easily function without this
>  additional package. This module may provide some less-common
>  functionality that a user might want. DNF defaults to *not* installing
>  Suggests: packages automatically.
>  
>  Traditionally, we have only supported "Requires" dependencies and thus
>  the creation of install media (Live and otherwise) has been relatively
>  straightforward: we create a kickstart file that is fed into the
>  compose process containing a list of packages and groups that we want
>  installed onto the target system and the compose process automatically
>  pulls in all of the dependencies. However, with the advent of weak
>  dependencies, we have new questions that need answering about how this
>  compose process should work. (We also need to investigate what exactly
>  happens with the tools we have today - some of which still use yum, not
>  DNF - when weak dependencies are added to the mix).
>  
>  From my perspective, there are three ways that we could choose to go:
>  
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system)
>  
>  2) Include *all* dependencies - Requires, Recommends and Suggests - on
>  the install media. The installer would still follow DNF defaults, so
>  the target system would get only the Requires and Recommends packages
>  unless the Suggests: packages are explicitly selected (which will also
>  require the creation of additional comps.xml changes to include the
>  Suggests packages)
>  
>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff)
>  
>  
>  Note that at the moment, DNF itself does not have a configuration
>  option to tweak the default install behavior, so 'dnf install'
>  effectively treats Recommends the same way as Requires (but 'dnf
>  remove' will treat them differently, of course). I discussed this with
>  the DNF developers this morning and they hope to have a configuration
>  option and/or command-line argument available to change this behavior
>  before Beta Freeze, so we should still be able to ship F23 with any of
>  the above options.
>  
>  I think the best time to make these decisions is now, well in advance
>  of the Alpha Freeze so we have time to make adjustments as needed.
>  Thank you for reading to the end, I know the above has been a wall-o'
>  -text. 
I think without some flag in dnf that anaconda can toggle on the users request 
we should only include Requires and Recommends on the media  if users have a 
toggle to say also include Suggested packages then and only then should we 
include Suggests.  the experience for installs from Media should match 
installs from the network.   As we have shown time and time again manually 
managed lists do not scale or work well. so i think defining suggests in comps 
groups will be prone to a lot of issues.

Dennis

[Stephen Gallagher]

On Fri, 2015-07-10 at 13:06 -0500, Dennis Gilmore wrote:
>  On Friday, July 10, 2015 08:05:24 AM Stephen Gallagher wrote:
>  > (Please keep the conversation on the devel list; I'm CCing it the 
>  > rel
>  > -eng list to make sure all the relevant people see the initial 
>  > message)
>  > 
>  > This past week, the Fedora Packaging Committee approved the use of
>  > "weak dependencies" in Fedora. What this means is that RPM packages 
>  > can
>  > now have three levels of dependency-resolution: Requires, 
>  > Recommends
>  > and Suggests.
>  >  * Requires: the requested package cannot function without this
>  > additional package installed
>  >  * Recommends: the requested package can function in some minimal
>  > capacity without this additional package installed, but the 
>  > majority of
>  > installations will want it for full productivity. These are usually
>  > core plugins for the primary package. DNF defaults to installing
>  > Recommends: dependencies automatically.
>  >  * Suggests: the requested package can easily function without this
>  > additional package. This module may provide some less-common
>  > functionality that a user might want. DNF defaults to *not* 
>  > installing
>  > Suggests: packages automatically.
>  > 
>  > Traditionally, we have only supported "Requires" dependencies and 
>  > thus
>  > the creation of install media (Live and otherwise) has been 
>  > relatively
>  > straightforward: we create a kickstart file that is fed into the
>  > compose process containing a list of packages and groups that we 
>  > want
>  > installed onto the target system and the compose process 
>  > automatically
>  > pulls in all of the dependencies. However, with the advent of weak
>  > dependencies, we have new questions that need answering about how 
>  > this
>  > compose process should work. (We also need to investigate what 
>  > exactly
>  > happens with the tools we have today - some of which still use yum, 
>  > not
>  > DNF - when weak dependencies are added to the mix).
>  > 
>  > From my perspective, there are three ways that we could choose to 
>  > go:
>  > 
>  > 1) Follow the default DNF behavior: Requires: and Recommends: 
>  > packages
>  > are included on the install media (and therefore also installed
>  > together onto the target system)
>  > 
>  > 2) Include *all* dependencies - Requires, Recommends and Suggests - 
>  > on
>  > the install media. The installer would still follow DNF defaults, 
>  > so
>  > the target system would get only the Requires and Recommends 
>  > packages
>  > unless the Suggests: packages are explicitly selected (which will 
>  > also
>  > require the creation of additional comps.xml changes to include the
>  > Suggests packages)
>  > 
>  > 3) Include only Requires: dependencies by default and require spin
>  > -kickstarts owners to explicitly add any Recommends or Suggests
>  > packages that they also want to include. Packages added explicitly 
>  > will
>  > be installed as described in 2) (requiring additional comps.xml 
>  > changes
>  > to include Suggests stuff)
>  > 
>  > 
>  > Note that at the moment, DNF itself does not have a configuration
>  > option to tweak the default install behavior, so 'dnf install'
>  > effectively treats Recommends the same way as Requires (but 'dnf
>  > remove' will treat them differently, of course). I discussed this 
>  > with
>  > the DNF developers this morning and they hope to have a 
>  > configuration
>  > option and/or command-line argument available to change this 
>  > behavior
>  > before Beta Freeze, so we should still be able to ship F23 with any 
>  > of
>  > the above options.
>  > 
>  > I think the best time to make these decisions is now, well in 
>  > advance
>  > of the Alpha Freeze so we have time to make adjustments as needed.
>  > Thank you for reading to the end, I know the above has been a wall
>  > -o'
>  > -text.
>  
>  I think without some flag in dnf that anaconda can toggle on the 
>  users request 
>  we should only include Requires and Recommends on the media  if users 
>  have a 
>  toggle to say also include Suggested packages then and only then 
>  should we 
>  include Suggests.  the experience for installs from Media should 
>  match 
>  installs from the network.   As we have shown time and time again 
>  manually 
>  managed lists do not scale or work well. so i think defining suggests 
>  in comps 
>  groups will be prone to a lot of issues.
>   
I think 1) makes the most sense as long as we have the following test
cases that pass:

Assuming a package named "engine" which Recommends: "common-plugin"
and
Suggests: "uncommon-plugin":

* A kickstart that includes "engine" will result in an install medium
that includes "common-plugin" and does not include "uncommon-plugin"
 * Installing from this medium (and no network) with an environment
group that includes "engine" will install both "engine" and
"common
-plugin" and will not encounter an error by not being able to locate
"uncommon-plugin".

* A kickstart that includes "engine" but also includes "-uncommon
-plugin" (explicitly excluding it from the medium) will result in a
medium that includes only "engine".
 * Any environment group that includes "engine" will appear in Anaconda
(as long as that group does not require "common-plugin" as a mandatory
package).
 * Installing from this medium (and no network) with an environment
group that includes "engine" will install "engine" and will not
encounter an error by not being able to locate "common-plugin" or
"uncommon-plugin".

[Matthew Miller]

On Fri, Jul 10, 2015 at 08:05:24AM -0400, Stephen Gallagher wrote:
>  1) Follow the default DNF behavior: Requires: and Recommends:
> packages
>  are included on the install media (and therefore also installed
>  together onto the target system) 
Can this have the inverse of the case in #3 (where Recommends are
followed by default, but could be explicitly removed by choice)?

>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff) 
I think I'm in favor of this one. I think a lot of the Recommends are
likely to be there because the recommended package is large or has a
large dep chain, and that might not be ideal for the install media.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Josh Boyer]

On Fri, Jul 10, 2015 at 5:03 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Fri, Jul 10, 2015 at 08:05:24AM -0400, Stephen Gallagher wrote:
> > 1) Follow the default DNF behavior: Requires: and Recommends: packages
> > are included on the install media (and therefore also installed
> > together onto the target system)
>
>  Can this have the inverse of the case in #3 (where Recommends are
>  followed by default, but could be explicitly removed by choice)?
>
> > 3) Include only Requires: dependencies by default and require spin
> > -kickstarts owners to explicitly add any Recommends or Suggests
> > packages that they also want to include. Packages added explicitly will
> > be installed as described in 2) (requiring additional comps.xml changes
> > to include Suggests stuff)
>
>  I think I'm in favor of this one. I think a lot of the Recommends are
>  likely to be there because the recommended package is large or has a
>  large dep chain, and that might not be ideal for the install media. 
Then maybe packagers should be using Suggests for those additional
packages.  Recommends to me means "the packager thinks the best
experience includes this functionality."  That is certainly still a
tradeoff, but it is a much stronger implication on the packagers part.
It also matches the later installation experience.

josh

[Neal Gompa]

On Fri, Jul 10, 2015 at 8:05 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt;
wrote:

>  From my perspective, there are three ways that we could choose to go:
>
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system)
>
>  
​I think this option makes the most sense, as it captures the current
behavior of DNF into the composition process. I honestly do not believe it
would make sense to allow the default behavior to differ from DNF,
especially as the vast majority of composes now are live images, making it
basically impossible to customize pre-install.​



>  2) Include *all* dependencies - Requires, Recommends and Suggests -
> on
>  the install media. The installer would still follow DNF defaults, so
>  the target system would get only the Requires and Recommends packages
>  unless the Suggests: packages are explicitly selected (which will also
>  require the creation of additional comps.xml changes to include the
>  Suggests packages)
>
>  
​While I appreciate the idea for completeness, I do not think this would go
over well as we update our packages to actually utilize weak dependencies
efficiently. However, I would be in favor of a kickstart parameter that
could switch on and off the inclusion of recommended and suggested packages
in a compose.

For example, in the %packages section, "--no_recommended_packages" and
"--add_suggested_packages" switches could be handy to alter the default
behavior to whatever a composer would want.



>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff)
>
>  
This is absolutely foolhardy, as we are fully deviating from ​how DNF
behaves and enshrining the hacks with comps that we simply do not need
anymore.
​


>  Note that at the moment, DNF itself does not have a configuration
>  option to tweak the default install behavior, so 'dnf install'
>  effectively treats Recommends the same way as Requires (but 'dnf
>  remove' will treat them differently, of course). I discussed this with
>  the DNF developers this morning and they hope to have a configuration
>  option and/or command-line argument available to change this behavior
>  before Beta Freeze, so we should still be able to ship F23 with any of
>  the above options.
>
>  
​Excellent!​



>  I think the best time to make these decisions is now, well in
> advance
>  of the Alpha Freeze so we have time to make adjustments as needed.
>  Thank you for reading to the end, I know the above has been a wall-o'
>  -text.
>  
​I completely agree, as the earlier we can decide on these things, the
better we'll all be. Thank you for bringing it up!



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jon]

On Fri, Jul 10, 2015 at 7:05 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt;
wrote:

>  (Please keep the conversation on the devel list; I'm CCing it the
> rel
>  -eng list to make sure all the relevant people see the initial message)
>  
Nod, thanks for that!


>  This past week, the Fedora Packaging Committee approved the use of
>  "weak dependencies" in Fedora. What this means is that RPM packages can
>  now have three levels of dependency-resolution: Requires, Recommends
>  and Suggests.
>   * Requires: the requested package cannot function without this
>  additional package installed
>   * Recommends: the requested package can function in some minimal
>  capacity without this additional package installed, but the majority of
>  installations will want it for full productivity. These are usually
>  core plugins for the primary package. DNF defaults to installing
>  Recommends: dependencies automatically.
>   * Suggests: the requested package can easily function without this
>  additional package. This module may provide some less-common
>  functionality that a user might want. DNF defaults to *not* installing
>  Suggests: packages automatically.
>
>  
Very interesting. I hope this capability is used to reduce the greediness
of the overall package dependency graph.
However I do anticipate a bit of package drama in reducing dependency
versus functionality.
The implication seems to be a middle ground, reduce the dependency graph at
the risk of reduced features.
Or at least that is my feeling from a releng & base working group
perspective.


>  Traditionally, we have only supported "Requires"
> dependencies and thus
>  the creation of install media (Live and otherwise) has been relatively
>  straightforward: we create a kickstart file that is fed into the
>  compose process containing a list of packages and groups that we want
>  installed onto the target system and the compose process automatically
>  pulls in all of the dependencies. However, with the advent of weak
>  dependencies, we have new questions that need answering about how this
>  compose process should work. (We also need to investigate what exactly
>  happens with the tools we have today - some of which still use yum, not
>  DNF - when weak dependencies are added to the mix).
>
>  From my perspective, there are three ways that we could choose to go:
>
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system)
>
>  2) Include *all* dependencies - Requires, Recommends and Suggests - on
>  the install media. The installer would still follow DNF defaults, so
>  the target system would get only the Requires and Recommends packages
>  unless the Suggests: packages are explicitly selected (which will also
>  require the creation of additional comps.xml changes to include the
>  Suggests packages)
>
>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff)
>
>
>  
For now I suggest we keep with strict 'Requires' only on install media
generation (if that is possible), but ask the same questions again next
cycle.
Let's be conservative here; it's a new feature.
I'd say let the ecosystem evolve a bit before asking this question again,
particularly the Anaconda tools.
The DNF tools for sure need to evolve a bit before weak dependencies become
a thing. (it all seems related)



>  Note that at the moment, DNF itself does not have a configuration
>  option to tweak the default install behavior, so 'dnf install'
>  effectively treats Recommends the same way as Requires (but 'dnf
>  remove' will treat them differently, of course). I discussed this with
>  the DNF developers this morning and they hope to have a configuration
>  option and/or command-line argument available to change this behavior
>  before Beta Freeze, so we should still be able to ship F23 with any of
>  the above options.
>
>  I think the best time to make these decisions is now, well in advance
>  of the Alpha Freeze so we have time to make adjustments as needed.
>  Thank you for reading to the end, I know the above has been a wall-o'
>  -text.
>  
Now is the time to agree weak deps are here, but it's not a light switch
Boolean type thing to change in the rel-eng side.
We can wait a while for package maintainers embrace the new hotness.
And.. I'd like to reward maintainers for embracing the new weak dep stuff.
(Fedora badge anyone?)
Anyways... it would be great to let the compose process stay the same for
now.

To be specific towards the end:
* Requires: yes
* Recommend: probably no  (but maybe, let them be explicit in the compose)
* Suggest: no  (let them be explicitly specified in the compose if they are
of high value for that spin or variant, ignore them otherwise)

Seems like the package-set for a variant or spin will become more explicit.
Which is not bad, but needs to be tested!

Besides that, I'd like to see how comps.xml handles these new relationships.

Thanks!

-- 

-Jon Disnard

[Stephen Gallagher]

On Fri, 2015-07-10 at 22:53 -0500, Jon wrote:
>  
>  
>  On Fri, Jul 10, 2015 at 7:05 AM, Stephen Gallagher <
>  sgallagh(a)redhat.com&gt; wrote: 
...
>  > From my perspective, there are three ways that we could choose
> to 
>  > go:
>  > 
>  > 1) Follow the default DNF behavior: Requires: and Recommends: 
>  > packages
>  > are included on the install media (and therefore also installed
>  > together onto the target system)
>  > 
>  > 2) Include *all* dependencies - Requires, Recommends and Suggests - 
>  > on
>  > the install media. The installer would still follow DNF defaults, 
>  > so
>  > the target system would get only the Requires and Recommends 
>  > packages
>  > unless the Suggests: packages are explicitly selected (which will 
>  > also
>  > require the creation of additional comps.xml changes to include the
>  > Suggests packages)
>  > 
>  > 3) Include only Requires: dependencies by default and require spin
>  > -kickstarts owners to explicitly add any Recommends or Suggests
>  > packages that they also want to include. Packages added explicitly 
>  > will
>  > be installed as described in 2) (requiring additional comps.xml 
>  > changes
>  > to include Suggests stuff)
>  > 
>  > 
>  For now I suggest we keep with strict 'Requires' only on install 
>  media generation (if that is possible), but ask the same questions 
>  again next cycle.
>  Let's be conservative here; it's a new feature.
>  I'd say let the ecosystem evolve a bit before asking this question 
>  again, particularly the Anaconda tools.
>  The DNF tools for sure need to evolve a bit before weak dependencies 
>  become a thing. (it all seems related)
>   
Well, weak deps are here; they're in the packaging guidelines now, so
we need to figure out how to deal with them (even if the decision is
"expressly ignore them").


>   
>  >  Note that at the moment, DNF itself does not have a configuration
>  > option to tweak the default install behavior, so 'dnf install'
>  > effectively treats Recommends the same way as Requires (but 'dnf
>  > remove' will treat them differently, of course). I discussed this 
>  > with
>  > the DNF developers this morning and they hope to have a 
>  > configuration
>  > option and/or command-line argument available to change this 
>  > behavior
>  > before Beta Freeze, so we should still be able to ship F23 with any 
>  > of
>  > the above options.
>  > 
>  > I think the best time to make these decisions is now, well in 
>  > advance
>  > of the Alpha Freeze so we have time to make adjustments as needed.
>  > Thank you for reading to the end, I know the above has been a wall
>  > -o'
>  > -text.
>  Now is the time to agree weak deps are here, but it's not a light 
>  switch Boolean type thing to change in the rel-eng side.We can wait a 
>  while for package maintainers embrace the new hotness. 
>  And.. I'd like to reward maintainers for embracing the new weak dep 
>  stuff. (Fedora badge anyone?) 
I like this idea.

>  Anyways... it would be great to let the compose process stay the same
>
>  for now.
>   
Well, that's why I called out the need for testing; I'm not sure that
the compose process will remain the same in F23 as it was in F22
without conscious effort, because I *think* the default case will be
that using dnf to gather the packages for the compose will start
pulling in Recommends packages. So if we don't want that to happen, it
may require an explicit choice and modification of the call to dnf.
(Yes, I'm aware that a lot of our compose tasks still use yum, but I
thought I remembered that most if not all of them were scheduled to
migrate to dnf this cycle).

>  To be specific towards the end:
>  * Requires: yes
>  * Recommend: probably no  (but maybe, let them be explicit in the 
>  compose)
>  * Suggest: no  (let them be explicitly specified in the compose if 
>  they are of high value for that spin or variant, ignore them 
>  otherwise)
>  
>  Seems like the package-set for a variant or spin will become more 
>  explicit. Which is not bad, but needs to be tested!
>  
>  Besides that, I'd like to see how comps.xml handles these new 
>  relationships. 
comps.xml should be completely unaware of them, I think. Comps only
specifies the set of packages that have to be in a group in order to be
able to install it. It is left up to the dependency solver to figure
out how that is satisfied.

[Radek Holy]

----- Original Message -----
>  From: "Stephen Gallagher" <sgallagh(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Cc: rel-eng(a)lists.fedoraproject.org
>  Sent: Friday, July 10, 2015 2:05:24 PM
>  Subject: RPM Weak Dependencies and the install media compose process
>  
>  (Please keep the conversation on the devel list; I'm CCing it the rel
>  -eng list to make sure all the relevant people see the initial message)
>  
>  This past week, the Fedora Packaging Committee approved the use of
>  "weak dependencies" in Fedora. What this means is that RPM packages can
>  now have three levels of dependency-resolution: Requires, Recommends
>  and Suggests.
>   * Requires: the requested package cannot function without this
>  additional package installed
>   * Recommends: the requested package can function in some minimal
>  capacity without this additional package installed, but the majority of
>  installations will want it for full productivity. These are usually
>  core plugins for the primary package. DNF defaults to installing
>  Recommends: dependencies automatically.
>   * Suggests: the requested package can easily function without this
>  additional package. This module may provide some less-common
>  functionality that a user might want. DNF defaults to *not* installing
>  Suggests: packages automatically.
>  
>  Traditionally, we have only supported "Requires" dependencies and thus
>  the creation of install media (Live and otherwise) has been relatively
>  straightforward: we create a kickstart file that is fed into the
>  compose process containing a list of packages and groups that we want
>  installed onto the target system and the compose process automatically
>  pulls in all of the dependencies. However, with the advent of weak
>  dependencies, we have new questions that need answering about how this
>  compose process should work. (We also need to investigate what exactly
>  happens with the tools we have today - some of which still use yum, not
>  DNF - when weak dependencies are added to the mix).
>  
>  From my perspective, there are three ways that we could choose to go:
>  
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system)
>  
>  2) Include *all* dependencies - Requires, Recommends and Suggests - on
>  the install media. The installer would still follow DNF defaults, so
>  the target system would get only the Requires and Recommends packages
>  unless the Suggests: packages are explicitly selected (which will also
>  require the creation of additional comps.xml changes to include the
>  Suggests packages)
>  
>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff)
>  
>  
>  Note that at the moment, DNF itself does not have a configuration
>  option to tweak the default install behavior, so 'dnf install'
>  effectively treats Recommends the same way as Requires (but 'dnf
>  remove' will treat them differently, of course). 
Let me just clarify that there is still one little difference. A package cannot be
installed if one of its *required* packages is not available while an unavailable
*recommended* package does not block the installation.

>  I discussed this with
>  the DNF developers this morning and they hope to have a configuration
>  option and/or command-line argument available to change this behavior
>  before Beta Freeze, so we should still be able to ship F23 with any of
>  the above options.
>  
>  I think the best time to make these decisions is now, well in advance
>  of the Alpha Freeze so we have time to make adjustments as needed.
>  Thank you for reading to the end, I know the above has been a wall-o'
>  -text. 
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech

Proposal: Drop comps

[Vít Ondruch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Can we just drop comps entirely (or at least trim them down
significantly)? I know that this will not happen from day to day, but I
see the comps just as an ugly workaround for missing weak dependencies,
which we have now.


Vít




Dne 10.7.2015 v 14:05 Stephen Gallagher napsal(a):
>  (Please keep the conversation on the devel list; I'm CCing it the
> rel
>  -eng list to make sure all the relevant people see the initial message)
>
>  This past week, the Fedora Packaging Committee approved the use of
>  "weak dependencies" in Fedora. What this means is that RPM packages can
>  now have three levels of dependency-resolution: Requires, Recommends
>  and Suggests.
>   * Requires: the requested package cannot function without this
>  additional package installed
>   * Recommends: the requested package can function in some minimal
>  capacity without this additional package installed, but the majority of
>  installations will want it for full productivity. These are usually
>  core plugins for the primary package. DNF defaults to installing
>  Recommends: dependencies automatically.
>   * Suggests: the requested package can easily function without this
>  additional package. This module may provide some less-common
>  functionality that a user might want. DNF defaults to *not* installing
>  Suggests: packages automatically.
>
>  Traditionally, we have only supported "Requires" dependencies and thus
>  the creation of install media (Live and otherwise) has been relatively
>  straightforward: we create a kickstart file that is fed into the
>  compose process containing a list of packages and groups that we want
>  installed onto the target system and the compose process automatically
>  pulls in all of the dependencies. However, with the advent of weak
>  dependencies, we have new questions that need answering about how this
>  compose process should work. (We also need to investigate what exactly
>  happens with the tools we have today - some of which still use yum, not
>  DNF - when weak dependencies are added to the mix).
>
>  From my perspective, there are three ways that we could choose to go:
>
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system)
>
>  2) Include *all* dependencies - Requires, Recommends and Suggests - on
>  the install media. The installer would still follow DNF defaults, so
>  the target system would get only the Requires and Recommends packages
>  unless the Suggests: packages are explicitly selected (which will also
>  require the creation of additional comps.xml changes to include the
>  Suggests packages)
>
>  3) Include only Requires: dependencies by default and require spin
>  -kickstarts owners to explicitly add any Recommends or Suggests
>  packages that they also want to include. Packages added explicitly will
>  be installed as described in 2) (requiring additional comps.xml changes
>  to include Suggests stuff)
>
>
>  Note that at the moment, DNF itself does not have a configuration
>  option to tweak the default install behavior, so 'dnf install'
>  effectively treats Recommends the same way as Requires (but 'dnf
>  remove' will treat them differently, of course). I discussed this with
>  the DNF developers this morning and they hope to have a configuration
>  option and/or command-line argument available to change this behavior
>  before Beta Freeze, so we should still be able to ship F23 with any of
>  the above options.
>
>  I think the best time to make these decisions is now, well in advance
>  of the Alpha Freeze so we have time to make adjustments as needed.
>  Thank you for reading to the end, I know the above has been a wall-o'
>  -text.
>
>  
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVpMSzAAoJEAzgnueZF7h8epkP/0LH9wzwx5XjS41lOnG3cr5C
> 2O5fEOwODffCa6une0tiJDTLvXLyx9BthEKClRHImpNFEVXg9QGGYurWbqhRfeJA
> Zvc1Wzuvlf2s5iNEMFw7c8S1s3FK4/ytX4hMSx5F/9RAENq/qKxKEUU6BjiP6RxF
> qP7e5yaN+y6QEuogWe2j4caqD/mfP8ZhanrvHO/KAOv8a+OAp0LZXF4uuHbfxfak
> 0OJw2/q9oKoO8ww5CiNJdRk+vMEXnIOT9XzMdqcpV5/GzKt42wNFqusT84Shvih2
> nl2PB6Wh1rPL8oUwmQsWToEpoN0Zjh7FDVqZcbn4ja7depmJ0ub0cNTl4eJ+1AJc
> fc5c+pZ5qLUKokTOvk708yy5pq2HbByqBTeBHxG51YwLZd2bUlZBQbyfadfM66Z3
> FzyiEEjxA+V/mm0VXoA1kuEN1+8BnW25atifnvTLcGs5doGnEivDogaCDi8GDdCt
> dR/ZLPCJySNcZJPROfrlKWd6PSUfX/M3bzdaBJcIQL/klO45dYTGolxyr0R/Muf5
> B/apLMsVTyLE8Qp4HpmcmjKft1rgXNAHpe3EyXD39dhrtbpmZyMYwjO029yYAi6R
> tQa2ISnuQO1hMv78A5KhseKMyHv4XKgeMaXwwdpKExZh2u8otgCBZXYq/G7MiMWc
> 3UQOteXvXhgWXjW5y7m4
> =EPjN
> -----END PGP SIGNATURE-----

Proposal: Drop comps

[Neal Gompa]

On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>
>  Can we just drop comps entirely (or at least trim them down
>  significantly)? I know that this will not happen from day to day, but I see
>  the comps just as an ugly workaround for missing weak dependencies, which
>  we have now.
>
>
>  Vít
>
>
>
>
>  Dne 10.7.2015 v 14:05 Stephen Gallagher napsal(a):
>  > (Please keep the conversation on the devel list; I'm CCing it the rel
>  > -eng list to make sure all the relevant people see the initial message)
>  >
>  > This past week, the Fedora Packaging Committee approved the use of
>  > "weak dependencies" in Fedora. What this means is that RPM packages can
>  > now have three levels of dependency-resolution: Requires, Recommends
>  > and Suggests.
>  >  * Requires: the requested package cannot function without this
>  > additional package installed
>  >  * Recommends: the requested package can function in some minimal
>  > capacity without this additional package installed, but the majority of
>  > installations will want it for full productivity. These are usually
>  > core plugins for the primary package. DNF defaults to installing
>  > Recommends: dependencies automatically.
>  >  * Suggests: the requested package can easily function without this
>  > additional package. This module may provide some less-common
>  > functionality that a user might want. DNF defaults to *not* installing
>  > Suggests: packages automatically.
>  >
>  > Traditionally, we have only supported "Requires" dependencies and thus
>  > the creation of install media (Live and otherwise) has been relatively
>  > straightforward: we create a kickstart file that is fed into the
>  > compose process containing a list of packages and groups that we want
>  > installed onto the target system and the compose process automatically
>  > pulls in all of the dependencies. However, with the advent of weak
>  > dependencies, we have new questions that need answering about how this
>  > compose process should work. (We also need to investigate what exactly
>  > happens with the tools we have today - some of which still use yum, not
>  > DNF - when weak dependencies are added to the mix).
>  >
>  > From my perspective, there are three ways that we could choose to go:
>  >
>  > 1) Follow the default DNF behavior: Requires: and Recommends: packages
>  > are included on the install media (and therefore also installed
>  > together onto the target system)
>  >
>  > 2) Include *all* dependencies - Requires, Recommends and Suggests - on
>  > the install media. The installer would still follow DNF defaults, so
>  > the target system would get only the Requires and Recommends packages
>  > unless the Suggests: packages are explicitly selected (which will also
>  > require the creation of additional comps.xml changes to include the
>  > Suggests packages)
>  >
>  > 3) Include only Requires: dependencies by default and require spin
>  > -kickstarts owners to explicitly add any Recommends or Suggests
>  > packages that they also want to include. Packages added explicitly will
>  > be installed as described in 2) (requiring additional comps.xml changes
>  > to include Suggests stuff)
>  >
>  >
>  > Note that at the moment, DNF itself does not have a configuration
>  > option to tweak the default install behavior, so 'dnf install'
>  > effectively treats Recommends the same way as Requires (but 'dnf
>  > remove' will treat them differently, of course). I discussed this with
>  > the DNF developers this morning and they hope to have a configuration
>  > option and/or command-line argument available to change this behavior
>  > before Beta Freeze, so we should still be able to ship F23 with any of
>  > the above options.
>  >
>  > I think the best time to make these decisions is now, well in advance
>  > of the Alpha Freeze so we have time to make adjustments as needed.
>  > Thank you for reading to the end, I know the above has been a wall-o'
>  > -text.
>  >
>  >
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v2
> >
> >  iQIcBAEBCAAGBQJVpMSzAAoJEAzgnueZF7h8epkP/0LH9wzwx5XjS41lOnG3cr5C
> >  2O5fEOwODffCa6une0tiJDTLvXLyx9BthEKClRHImpNFEVXg9QGGYurWbqhRfeJA
> >  Zvc1Wzuvlf2s5iNEMFw7c8S1s3FK4/ytX4hMSx5F/9RAENq/qKxKEUU6BjiP6RxF
> >  qP7e5yaN+y6QEuogWe2j4caqD/mfP8ZhanrvHO/KAOv8a+OAp0LZXF4uuHbfxfak
> >  0OJw2/q9oKoO8ww5CiNJdRk+vMEXnIOT9XzMdqcpV5/GzKt42wNFqusT84Shvih2
> >  nl2PB6Wh1rPL8oUwmQsWToEpoN0Zjh7FDVqZcbn4ja7depmJ0ub0cNTl4eJ+1AJc
> >  fc5c+pZ5qLUKokTOvk708yy5pq2HbByqBTeBHxG51YwLZd2bUlZBQbyfadfM66Z3
> >  FzyiEEjxA+V/mm0VXoA1kuEN1+8BnW25atifnvTLcGs5doGnEivDogaCDi8GDdCt
> >  dR/ZLPCJySNcZJPROfrlKWd6PSUfX/M3bzdaBJcIQL/klO45dYTGolxyr0R/Muf5
> >  B/apLMsVTyLE8Qp4HpmcmjKft1rgXNAHpe3EyXD39dhrtbpmZyMYwjO029yYAi6R
> >  tQa2ISnuQO1hMv78A5KhseKMyHv4XKgeMaXwwdpKExZh2u8otgCBZXYq/G7MiMWc
> >  3UQOteXvXhgWXjW5y7m4
> >  =EPjN
> >  -----END PGP SIGNATURE----- 
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
If we did that, we'd need to switch to some other means of grouping
packages.
​Borrowing a bit from how the Debian/Ubuntu folks do things, probably
massive virtual packages/metapackages would work well for this purpose. ​Or
perhaps a "type" of package that defines groups to provide a similar
function to metapackages without requiring garbage empty tarballs.


-- 
真実はいつも一つ！/ Always, there's only one truth!

Proposal: Drop comps

[Vít Ondruch]

Dne 14.7.2015 v 11:49 Neal Gompa napsal(a):
>  On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch <vondruch(a)redhat.com
> <mailto:[e-mail]>>wrote: > >
>  Can we just drop comps entirely (or at least trim them down
>  significantly)? I know that this will not happen from day to day, but
>  I see the comps just as an ugly workaround for missing weak
>  dependencies, which we have now.
>
>
>  Vít
>
>
>
>  > > If we did that, we'd need to switch to some other means of grouping
packages. ​Borrowing a bit from how the Debian/Ubuntu folks do things,
probably massive virtual packages/metapackages would work well for this
purpose. ​Or perhaps a "type" of package that defines groups to provide
a similar function to metapackages without requiring garbage empty
tarballs.
One advantage of comps/groups was that it allowed to uninstall
particular packages, where if you used Require at the same place, it
would be all or nothing. For example, rubyonrails group would be better
to express by Suggests dependencies then to have the group in comps. Not
mentioning that Gnome Software can handle meta package while it does not
handle groups (if I am not mistaken).

Vít

Proposal: Drop comps

[Neal Gompa]

On Tue, Jul 14, 2015 at 6:23 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:

>   Dne 14.7.2015 v 11:49 Neal Gompa napsal(a):
>  > On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch <vondruch(a)redhat.com
>  <mailto:[e-mail]> <vondruch(a)redhat.com&gt;&gt;wrote: > >
>
>  Can we just drop comps entirely (or at least trim them down
>  significantly)? I know that this will not happen from day to day, but I see
>  the comps just as an ugly workaround for missing weak dependencies, which
>  we have now.
>
>
>  Vít
>
>
>
>   > > > If we did that, we'd need to switch to some other means of
>  grouping packages. ​Borrowing a bit from how the Debian/Ubuntu folks do
>  things, probably massive virtual packages/metapackages would work well for
>  this purpose. ​Or perhaps a "type" of package that defines groups to
>  provide a similar function to metapackages without requiring garbage empty
>  tarballs.
>  One advantage of comps/groups was that it allowed to uninstall particular
>  packages, where if you used Require at the same place, it would be all or
>  nothing. For example, rubyonrails group would be better to express by
>  Suggests dependencies then to have the group in comps. Not mentioning that
>  Gnome Software can handle meta package while it does not handle groups (if
>  I am not mistaken).
>
>  Vít
>
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
​It should be possible to convert over to metapackages, but it would
probably make sense to convert a few groups and see how it should be shaken
out. Remember, we're a bit new to this weak dependency resolution thing! ;)​


-- 
Neal Gompa (FAS: ngompa)

Proposal: Drop comps

[Stephen Gallagher]

On Tue, 2015-07-14 at 10:13 +0200, Vít Ondruch wrote:
>  
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>  
>  Can we just drop comps entirely (or at least trim them down 
>  significantly)? I know that this will not happen from day to day, but 
>  I see the comps just as an ugly workaround for missing weak 
>  dependencies, which we have now.
>   

Comps has been used for this purpose sure (using the grouping mechanism
to specify optional packages in addition to critical ones). There are
other uses for comps that you're ignoring, though.

 * Anaconda relies on comps.xml environment groups to provide the
selection of which system to install on all network-install media.

 * The comps.xml groups also provide grouping for logically-connected
packages that do not map to weak dependencies well. (For example: an
"astronomy" group could pull in numerous scientific packages related to
astronomy)

I don't think there's any sense in removing comps.xml entirely, though
I'll be the first to say that it would be great if someone went through
and cleaned it up a bit. There's a lot of old cruft around. If someone
is interested in doing that in Rawhide after the F23 branch is
completed, that would be fantastic.

Proposal: Drop comps

[Vít Ondruch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dne 14.7.2015 v 15:21 Stephen Gallagher napsal(a):
>  On Tue, 2015-07-14 at 10:13 +0200, Vít Ondruch wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Can we just drop comps entirely (or at least trim them down
> > significantly)? I know that this will not happen from day to day, but
> > I see the comps just as an ugly workaround for missing weak
> > dependencies, which we have now.
> >
>
>
>  Comps has been used for this purpose sure (using the grouping mechanism
>  to specify optional packages in addition to critical ones). There are
>  other uses for comps that you're ignoring, though.
>
>   * Anaconda relies on comps.xml environment groups to provide the
>  selection of which system to install on all network-install media. 
True, but nothing which could not be changed if there is enough interest.

>   * The comps.xml groups also provide grouping for logically-connected
>  packages that do not map to weak dependencies well. (For example: an
>  "astronomy" group could pull in numerous scientific packages related to
>  astronomy) 
We can get back to metapackages, which are still used in Fedora in
various forms anyway.

>  I don't think there's any sense in removing comps.xml entirely, 
The problem with comps is that (IMO), it are not widely understand what
are they good for, how to manage them, how to change them etc, while the
package dependencies are quite well understood.

>   though
>  I'll be the first to say that it would be great if someone went through
>  and cleaned it up a bit. There's a lot of old cruft around. 
Sure, the first step is trimming down. For example, the rubyonrails
group could be removed and replaced by appropriate Suggests in
rubygem-rails (as soon as DNF supports the appropriate options [1] though).


Vít



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1229701
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVpRRpAAoJEAzgnueZF7h8NcUP/2ZCoiaui9H47I4k18Z9UlYj
> 0t9x+e0UYMS+sOaKtIa27onnkoxPKltrytFhg85qZ8qsPUyfzJVAFrX53xj/VHBX
> enNPAnQpY07khYGJVqn9JvwH2I7E1G/0K0h6z4oSqy/B/OGm/oCKqZw1VrDQD9uA
> qNfxY9qmk0XeStkPWo19CaCofs5Q6MxsUvButpd0P6IkuFGXU6zMTps9b/zqo7Fx
> 8yjK83ek4c+n7Y7UU9uAqxxicpsBlflocq7K3j+6qzzQNBoRYrQ6tn/PM5h+B0JE
> q1I/qRSx6mC9xDEWTGwvdVxSijU/hbArMKLlCJIJ3laiyLs6FMp3bBBTImPYNHHi
> 0SRPDqHzD8X+TcG11vcXE5zogEWR38AE3fNGy8mpWre/lnALJDuewVoFD01qo8jA
> z5iI35SQxOOCwW7euxJ1FkaArT6SJVA3pUV66VQL2+Kq9MG4c1ZQtehZUXxFYsww
> lM2XPpiVpg/dQoPSN7Yv5VbMfGwoYKq59RYLMzlsMUXH1mDsJLTQixlS2ZnrPvCX
> ifpxkWm4G8G4tlT2z8hA8d0hgz3miICBfguzxwXYFqx8PyVPyjUGM4NpC9OaUZKU
> sD+79Vs2g9uB6Jb4tcZnW1GAXdQ4PZwb3ucW7ipfFTgrLOyZ/xCXREWDdynXBPjp
> 7PkzhoNZxOL+ZB4HjjZs
> =TpSQ
> -----END PGP SIGNATURE-----

Proposal: Drop comps

[Kevin Fenzi]

On Tue, 14 Jul 2015 15:53:49 +0200
Vít Ondruch <vondruch(a)redhat.com&gt; wrote:

...snip...

>  >  * The comps.xml groups also provide grouping for
>  > logically-connected packages that do not map to weak dependencies
>  > well. (For example: an "astronomy" group could pull in numerous
>  > scientific packages related to astronomy)
>  
>  We can get back to metapackages, which are still used in Fedora in
>  various forms anyway. 
Metapackages have a lot of downsides too, only a few parts of which are
made better by weak dependencies. 

See: http://yum.baseurl.org/wiki/YumGroupsOverview

>  > I don't think there's any sense in removing comps.xml
> entirely,
>  
>  The problem with comps is that (IMO), it are not widely understand
>  what are they good for, how to manage them, how to change them etc,
>  while the package dependencies are quite well understood. 
So it's an education problem? 

>  >  though
>  > I'll be the first to say that it would be great if someone went
>  > through and cleaned it up a bit. There's a lot of old cruft around.
>  
>  Sure, the first step is trimming down. For example, the rubyonrails
>  group could be removed and replaced by appropriate Suggests in
>  rubygem-rails (as soon as DNF supports the appropriate options [1]
>  though). 
I suspect there may be lots of other cases too... 

kevin

Proposal: Drop comps

[Vít Ondruch]

Dne 14.7.2015 v 19:05 Kevin Fenzi napsal(a):
>  On Tue, 14 Jul 2015 15:53:49 +0200
>  Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>
>  ...snip...
>
> >>  * The comps.xml groups also provide grouping for
> >> logically-connected packages that do not map to weak dependencies
> >> well. (For example: an "astronomy" group could pull in numerous
> >> scientific packages related to astronomy)
> > We can get back to metapackages, which are still used in Fedora in
> > various forms anyway.
>  Metapackages have a lot of downsides too, only a few parts of which are
>  made better by weak dependencies. 
>
>  See: http://yum.baseurl.org/wiki/YumGroupsOverview 
I can't say this document is not confusing. But at least 3 points from
the "cons" section of metapackages could be removed IMO.


> >> I don't think there's any sense in removing comps.xml entirely,
> > The problem with comps is that (IMO), it are not widely understand
> > what are they good for, how to manage them, how to change them etc,
> > while the package dependencies are quite well understood.
>  So it's an education problem? 
How long are comps in Fedora? You can call it educational problem, but
this is just hiding of the problem IMO.

> >>  though
> >> I'll be the first to say that it would be great if someone went
> >> through and cleaned it up a bit. There's a lot of old cruft around.
> > Sure, the first step is trimming down. For example, the rubyonrails
> > group could be removed and replaced by appropriate Suggests in
> > rubygem-rails (as soon as DNF supports the appropriate options [1]
> > though).
>  I suspect there may be lots of other cases too... 
Definitely, this should be first step anyway. Looking into comps, here
is list of candidates:

anaconda-tools
base-x
eclipse
freeipa-server
haproxy
java
mingw32
mongodb
mysql
ocaml
ruby
rubyonrails
smb-server
tomcat
vagrant



Vít

Proposal: Drop comps

[Richard W.M. Jones]

On Wed, Jul 15, 2015 at 10:45:57AM +0200, Vít Ondruch wrote:
>  ocaml 
The comps.xml group for ocaml is pretty weird.  It has some mandatory
base packages, which are OK-ish (although there are some notable ones
missing such as ocaml-camlp4-devel and ocaml-labltk-devel).

Then it has a strange set of optional packages, which is a tiny subset
of the 89 OCaml packages in Fedora.

I've never used comps.xml and don't really know what it is good for,
except I know of the existence of some graphical tools which consume
it.  Richard Hughes's appdata seems like a more complete concept for
people that want that kind of thing.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

Proposal: Drop comps

[Ben Boeckel]

On Wed, 29 Jul, 2015 at 21:06:52 GMT, Richard W.M. Jones wrote:
>  I've never used comps.xml and don't really know what it is
> good for,
>  except I know of the existence of some graphical tools which consume
>  it.  Richard Hughes's appdata seems like a more complete concept for
>  people that want that kind of thing. 
I use it on my local repo to allow for easy initial setups with commands
like:

    dnf install @mathstuf-system-base @mathstuf-system-tools

and so on. It also exposes the groups in Anaconda (or did; I haven't
done a from-scratch install of a day-to-day system since...F19?). Much easier
than wrangling 100 packages names and doing things piecemeal.

--Ben

Proposal: Drop comps

[Adam Williamson]

On July 29, 2015 2:06:52 PM PDT, "Richard W.M. Jones" <
rjones(a)redhat.com&gt; wrote:
>  On Wed, Jul 15, 2015 at 10:45:57AM +0200, Vít Ondruch wrote:
>  > ocaml
>  
>  The comps.xml group for ocaml is pretty weird.  It has some mandatory
>  base packages, which are OK-ish (although there are some notable ones
>  missing such as ocaml-camlp4-devel and ocaml-labltk-devel).
>  
>  Then it has a strange set of optional packages, which is a tiny 
>  subset
>  of the 89 OCaml packages in Fedora.
>  
>  I've never used comps.xml and don't really know what it is good for,
>  except I know of the existence of some graphical tools which consume
>  it.  Richard Hughes's appdata seems like a more complete concept for
>  people that want that kind of thing. 
Our entire image building and delivery system is built around comps.
The groups in comps are used in defining the contents of live images
and product trees (and hence DVD images), and the arm disk images. The
groups defined in comps are the ones users can choose from in
netinst/dvd installs.

We could look at subbing in something better (the restrictions on
relationships between packages, groups and environments can be a pain),
but it'd need to be a careful process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Proposal: Drop comps

[Oron Peled]

On Tuesday 14 July 2015 10:13:43 Vít Ondruch wrote:
>  Can we just drop comps entirely (or at least trim them down
>  significantly)? I know that this will not happen from day to day, but I
>  see the comps just as an ugly workaround for missing weak dependencies,
>  which we have now. 
With all its ugliness, comps groups have another important feature -- localized *names*
and *descriptions*.

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron

Real programmers confuse halloween and christmas because OCT 31 = DEC 25.

Proposal: Drop comps

[Vít Ondruch]

Dne 14.7.2015 v 22:22 Oron Peled napsal(a):
>  On Tuesday 14 July 2015 10:13:43 Vít Ondruch wrote:
> > Can we just drop comps entirely (or at least trim them down
> > significantly)? I know that this will not happen from day to day, but I
> > see the comps just as an ugly workaround for missing weak dependencies,
> > which we have now.
>  With all its ugliness, comps groups have another important feature -- localized *names*
> and *descriptions*.
>  
Description and Summary can be localized in .spec file [1], where
supposedly "names" in comps terminology refers to "summary" in .spec
terminology. Including translations is encouraged in guidelines as well
[2, 3], unfortunately without any further details :/


Vít




[1]
http://stackoverflow.com/questions/30912383/rpm-package-spec-localization
[2] http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
[3] https://fedoraproject.org/wiki/Packaging:Guidelines#summary

Proposal: Drop comps

[Ralf Corsepius]

On 07/15/2015 10:20 AM, Vít Ondruch wrote:

>  Description and Summary can be localized in .spec file [1], where
>  supposedly "names" in comps terminology refers to "summary" in .spec
>  terminology. Including translations is encouraged in guidelines as well
>  [2, 3], unfortunately without any further details :/ 
I don't think localized summaries and descriptions are applicable in 
distributions like Fedora, where packages are maintained by individuals.

IMO, making localized summaries/descrs. helpful would require a 
multilingal team of translators/packagers, whose sole task it would have 
to be to add translations for a predefined set of languages to maintain 
them.

That said, I don't consider random packagers adding random translations 
to packages to be useful and to cause more problems than they solve.

Ralf

Proposal: Drop comps

[Mathieu Bridon]

-- 
Mathieu
On Wed, 2015-07-15 at 10:51 +0200, Ralf Corsepius wrote:
>  On 07/15/2015 10:20 AM, Vít Ondruch wrote:
>  
>  > Description and Summary can be localized in .spec file [1], where
>  > supposedly "names" in comps terminology refers to "summary" in 
>  > .spec
>  > terminology. Including translations is encouraged in guidelines as 
>  > well
>  > [2, 3], unfortunately without any further details :/
>  
>  I don't think localized summaries and descriptions are applicable in 
>  distributions like Fedora, where packages are maintained by 
>  individuals.
>  
>  IMO, making localized summaries/descrs. helpful would require a 
>  multilingal team of translators/packagers, whose sole task it would 
>  have 
>  to be to add translations for a predefined set of languages to 
>  maintain 
>  them.
>  
>  That said, I don't consider random packagers adding random 
>  translations 
>  to packages to be useful and to cause more problems than they solve. 
One problem with localized summaries/descriptions in packages, is that
you need a new build (and a new update in Bodhi, unless you wait 6
months for the next release) for it to reach users.

That's a lot of churn, and it's a terrible UX for users to keep
receiving "updates" that only add a translation of the
summary/description of the package (not the app itself!) in a language
they might not even care of.

Comps is much better on this point: we edit comps, and at the next
compose the change is taken into account.

Much less churn, especially for the users.


-- 
Mathieu

Proposal: Drop comps

[Vít Ondruch]

Dne 15.7.2015 v 12:21 Mathieu Bridon napsal(a):
>  On Wed, 2015-07-15 at 10:51 +0200, Ralf Corsepius wrote:
> > > On 07/15/2015 10:20 AM, Vít Ondruch wrote:
> > > 
> >> > > Description and Summary can be localized in .spec file [1], where
> >> > > supposedly "names" in comps terminology refers to
> "summary" in 
> >> > > .spec
> >> > > terminology. Including translations is encouraged in guidelines as 
> >> > > well
> >> > > [2, 3], unfortunately without any further details :/
> > > 
> > > I don't think localized summaries and descriptions are applicable in 
> > > distributions like Fedora, where packages are maintained by 
> > > individuals.
> > > 
> > > IMO, making localized summaries/descrs. helpful would require a 
> > > multilingal team of translators/packagers, whose sole task it would 
> > > have 
> > > to be to add translations for a predefined set of languages to 
> > > maintain 
> > > them.
> > > 
> > > That said, I don't consider random packagers adding random 
> > > translations 
> > > to packages to be useful and to cause more problems than they solve.
>  One problem with localized summaries/descriptions in packages, is that
>  you need a new build (and a new update in Bodhi, unless you wait 6
>  months for the next release) for it to reach users.
>
>  That's a lot of churn, and it's a terrible UX for users to keep
>  receiving "updates" that only add a translation of the
>  summary/description of the package (not the app itself!) in a language
>  they might not even care of.
>
>  Comps is much better on this point: we edit comps, and at the next
>  compose the change is taken into account.
>
>  Much less churn, especially for the users.
>  
But how is better to have translated just comps, when nothing else is
translated? And speaking of UI, comps translation are visible just in
Anaconda.


Vít

Proposal: Drop comps

[Martin Kolman]

On Wed, 2015-07-15 at 12:53 +0200, Vít Ondruch wrote:
>  Dne 15.7.2015 v 12:21 Mathieu Bridon napsal(a):
>  > On Wed, 2015-07-15 at 10:51 +0200, Ralf Corsepius wrote:
>  > > > On 07/15/2015 10:20 AM, Vít Ondruch wrote:
>  > > > 
>  > > > > > Description and Summary can be localized in .spec file [1], 
>  > > > > > where
>  > > > > > supposedly "names" in comps terminology refers to
> "summary" 
>  > > > > > in 
>  > > > > > .spec
>  > > > > > terminology. Including translations is encouraged in 
>  > > > > > guidelines as 
>  > > > > > well
>  > > > > > [2, 3], unfortunately without any further details :/
>  > > > 
>  > > > I don't think localized summaries and descriptions are 
>  > > > applicable in 
>  > > > distributions like Fedora, where packages are maintained by 
>  > > > individuals.
>  > > > 
>  > > > IMO, making localized summaries/descrs. helpful would require a 
>  > > > 
>  > > > multilingal team of translators/packagers, whose sole task it 
>  > > > would 
>  > > > have 
>  > > > to be to add translations for a predefined set of languages to 
>  > > > maintain 
>  > > > them.
>  > > > 
>  > > > That said, I don't consider random packagers adding random 
>  > > > translations 
>  > > > to packages to be useful and to cause more problems than they 
>  > > > solve.
>  > One problem with localized summaries/descriptions in packages, is 
>  > that
>  > you need a new build (and a new update in Bodhi, unless you wait 6
>  > months for the next release) for it to reach users.
>  > 
>  > That's a lot of churn, and it's a terrible UX for users to keep
>  > receiving "updates" that only add a translation of the
>  > summary/description of the package (not the app itself!) in a 
>  > language
>  > they might not even care of.
>  > 
>  > Comps is much better on this point: we edit comps, and at the next
>  > compose the change is taken into account.
>  > 
>  > Much less churn, especially for the users.
>  > 
>  
>  But how is better to have translated just comps, when nothing else is
>  translated? And speaking of UI, comps translation are visible just in
>  Anaconda. 
Not only in Anaconda - you can for example use the translated group
names to install groups with dnf group install.
>  
>  
>  Vít
>

Proposal: Drop comps

[Vít Ondruch]

Dne 15.7.2015 v 13:11 Martin Kolman napsal(a):
>  On Wed, 2015-07-15 at 12:53 +0200, Vít Ondruch wrote:
> > Dne 15.7.2015 v 12:21 Mathieu Bridon napsal(a):
> >> On Wed, 2015-07-15 at 10:51 +0200, Ralf Corsepius wrote:
> >>>> On 07/15/2015 10:20 AM, Vít Ondruch wrote:
> >>>>
> >>>>>> Description and Summary can be localized in .spec file [1], 
> >>>>>> where
> >>>>>> supposedly "names" in comps terminology refers to
> "summary" 
> >>>>>> in 
> >>>>>> .spec
> >>>>>> terminology. Including translations is encouraged in 
> >>>>>> guidelines as 
> >>>>>> well
> >>>>>> [2, 3], unfortunately without any further details :/
> >>>> I don't think localized summaries and descriptions are 
> >>>> applicable in 
> >>>> distributions like Fedora, where packages are maintained by 
> >>>> individuals.
> >>>>
> >>>> IMO, making localized summaries/descrs. helpful would require a 
> >>>>
> >>>> multilingal team of translators/packagers, whose sole task it 
> >>>> would 
> >>>> have 
> >>>> to be to add translations for a predefined set of languages to 
> >>>> maintain 
> >>>> them.
> >>>>
> >>>> That said, I don't consider random packagers adding random 
> >>>> translations 
> >>>> to packages to be useful and to cause more problems than they 
> >>>> solve.
> >> One problem with localized summaries/descriptions in packages, is 
> >> that
> >> you need a new build (and a new update in Bodhi, unless you wait 6
> >> months for the next release) for it to reach users.
> >>
> >> That's a lot of churn, and it's a terrible UX for users to keep
> >> receiving "updates" that only add a translation of the
> >> summary/description of the package (not the app itself!) in a 
> >> language
> >> they might not even care of.
> >>
> >> Comps is much better on this point: we edit comps, and at the next
> >> compose the change is taken into account.
> >>
> >> Much less churn, especially for the users.
> >>
> > But how is better to have translated just comps, when nothing else is
> > translated? And speaking of UI, comps translation are visible just in
> > Anaconda.
>  Not only in Anaconda - you can for example use the translated group
>  names to install groups with dnf group install. 
Do you think this is the way how regular users install software? May be
I should say next time GUI to be precise ...


Vít

Proposal: Drop comps

[Jens-Ulrik Petersen]

On Wed, Jul 15, 2015 at 8:39 PM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Do you think this is the way how regular users install software?
I think a lot of people install yum groups.  It is a pretty useful
functionality IMO.

If meta-packages become a viable replacement for comps then we can
seriously discuss removing comps.
Once comps became full of meta-packages then then job would be mostly done.
But I think more analysis of the meta-package approach is needed since
I believe it also has known downsides.

Jens

Proposal: Drop comps

[Christopher Meng]

On 8/11/15, Jens-Ulrik Petersen <petersen(a)redhat.com&gt; wrote:
>  On Wed, Jul 15, 2015 at 8:39 PM, Vít Ondruch
> <vondruch(a)redhat.com&gt; wrote:
> > Do you think this is the way how regular users install software?
>
>  I think a lot of people install yum groups.  It is a pretty useful
>  functionality IMO.
>
>  If meta-packages become a viable replacement for comps then we can
>  seriously discuss removing comps.
>  Once comps became full of meta-packages then then job would be mostly done.
>  But I think more analysis of the meta-package approach is needed since
>  I believe it also has known downsides. 
How to remove packages pulled by metapkg completely? Remove the
metapkg doesn't work, let users undo dnf history doesn't make sense at
least from my view.

-- 

Yours sincerely,
Christopher Meng

http://awk.io

Proposal: Drop comps

[Rex Dieter]

Vít Ondruch wrote:

>  Can we just drop comps entirely (or at least trim them down
>  significantly)? I know that this will not happen from day to day, but I
>  see the comps just as an ugly workaround for missing weak dependencies,
>  which we have now. 
Since your proposal to drop comps is based on an apparent false premise 
(that comps is just an ugly workaround...), no.

But +1 to trimming comps where it makes sense, assuming the conclusion of " 
install media compose process" is that Recommends: deps get installed by 
default (option 1 there)

-- rex

Proposal: Drop comps

[Matthias Clasen]

On Tue, 2015-07-14 at 10:13 +0200, Vít Ondruch wrote:
>  
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>  
>  Can we just drop comps entirely (or at least trim them down 
>  significantly)? I know that this will not happen from day to day, but 
>  I see the comps just as an ugly workaround for missing weak 
>  dependencies, which we have now. 
I've always thought that comps is just an ugly extra layer that only
adds more work and indirection, and few if any benefits. So, I welcome
this suggestion. Of course, as with all extra layers, once it is there,
it tends to accrete random functionality. As others have pointed out in
this thread, comps has things such as the (still mysterious to me)
environment groups, and some translated strings. I don't think any of
the examples that were mentioned so far would make me go "yes, we
should really have an xml file look-aside somewhere to hold this
functionality".

Proposal: Drop comps

[Adam Williamson]

On Wed, 2015-07-15 at 11:46 -0400, Matthias Clasen wrote:

>  this thread, comps has things such as the (still mysterious to me)
>  environment groups, 
Environment groups are, quite simply, groups of groups. That's the
entirety of the matter. They have a 'grouplist' of member groups that
are basically mandatory, and an 'optionlist' of optional groups, which
can be 'default' or not.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Rex Dieter]

Stephen Gallagher wrote:

>  From my perspective, there are three ways that we could choose to
> go:
>  
>  1) Follow the default DNF behavior: Requires: and Recommends: packages
>  are included on the install media (and therefore also installed
>  together onto the target system) 
+1 to this option

-- Rex