PackageKit in Fedora 15 (beta)

[Ilyes Gouta]

Hi,

Removing PackageKit In Fedora 14 was easy and painless since it causes up to
5 packages, all *really* related to PackageKit in the form of a yum-plugin
and few other things.

On Fedora 15, trying to "yum remove PackageKit" causes the system to attempt
removing up to 74 MB worth of software, including gdm, empathy, bluez and
gnome-shell !!!! Which is pointless.

Is it *really* required to have PackageKit so deeply integrated and made an
essential package on the system. AFAIK, it's essentially a helper and a
front-end for yum, right?

Is it possible to recover Fedora 14's lightweight dependencies set, for
PackageKit?

Thanks,

-Ilyes

[Reindl Harald]

Am 24.04.2011 20:04, schrieb Ilyes Gouta:
>  Hi,
>  
>  Removing PackageKit In Fedora 14 was easy and painless since it causes up to 5 packages,
> all *really* related to
>  PackageKit in the form of a yum-plugin and few other things.
>  
>  On Fedora 15, trying to "yum remove PackageKit" causes the system to attempt
> removing up to 74 MB worth of
>  software, including gdm, empathy, bluez and gnome-shell !!!! Which is pointless.
>  
>  Is it *really* required to have PackageKit so deeply integrated and made an essential
> package on the system. AFAIK,
>  it's essentially a helper and a front-end for yum, right?
>  
>  Is it possible to recover Fedora 14's lightweight dependencies set, for PackageKit?
>  
>  Thanks,
>  -Ilyes 
generellay the dependecies are getting bigger with every release
it should be possible to install a leightweigt system

yes, hard-disk are getting cheaper but time!
on the other hand running 20-30 Fedora VMs on a SAN-Storage
disk space is not so cheap as at home and the overhead multiplies

means: i like to remove everything that is not active used because
distupgrades and normal updates are much bigger and especially on
servers everything which is not installed is not vulnerable

[Ilyes Gouta]

Hi,

I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263

<https://bugzilla.redhat.com/show_bug.cgi?id=699263>-Ilyes

On Sun, Apr 24, 2011 at 7:12 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;wrote:

>  Am 24.04.2011 20:04, schrieb Ilyes Gouta:
>  > Hi,
>  >
>  > Removing PackageKit In Fedora 14 was easy and painless since it causes up
>  to 5 packages, all *really* related to
>  > PackageKit in the form of a yum-plugin and few other things.
>  >
>  > On Fedora 15, trying to "yum remove PackageKit" causes the system to
>  attempt removing up to 74 MB worth of
>  > software, including gdm, empathy, bluez and gnome-shell !!!! Which is
>  pointless.
>  >
>  > Is it *really* required to have PackageKit so deeply integrated and made
>  an essential package on the system. AFAIK,
>  > it's essentially a helper and a front-end for yum, right?
>  >
>  > Is it possible to recover Fedora 14's lightweight dependencies set, for
>  PackageKit?
>  >
>  > Thanks,
>  > -Ilyes
>
>  generellay the dependecies are getting bigger with every release
>  it should be possible to install a leightweigt system
>
>  yes, hard-disk are getting cheaper but time!
>  on the other hand running 20-30 Fedora VMs on a SAN-Storage
>  disk space is not so cheap as at home and the overhead multiplies
>
>  means: i like to remove everything that is not active used because
>  distupgrades and normal updates are much bigger and especially on
>  servers everything which is not installed is not vulnerable
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Richard Hughes]

On 24 April 2011 19:24, Ilyes Gouta <ilyes.gouta(a)gmail.com&gt; wrote:
>  I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263
I've commented on this, and closed it NOTABUG. Sorry.

Richard

[Rahul Sundaram]

On 04/24/2011 11:54 PM, Ilyes Gouta wrote:
>  Hi,
>
>  I filed a bug:  https://bugzilla.redhat.com/show_bug.cgi?id=699263
>
>  -Ilyes 
PackageKit isn't just a yum frontend and is likely to be integrated more
and more with key components as we go forward.  If you aren't actively
using the GNOME or KDE frontend, just remove those and leave the
framework as it is. 

Rahul

[Ilyes Gouta]

Rahul,

>  If you aren't actively using the GNOME or KDE frontend, just
> remove those 
and leave the
>  framework as it is. 
That was tough :)

AFAIK (and I might be wrong) deep PacakgeKit integration wasn't clearly
mentioned in Fedora 15's feature set list.

I was just asking if it was possible to recover to a situation where the
user would still have the choice, to use or not use PackageKit. That's all.
Fedora 14 gave that choice.

Alright, thanks for explaining!

-Ilyes

On Sun, Apr 24, 2011 at 7:55 PM, Rahul Sundaram <metherid(a)gmail.com&gt; wrote:

> On 04/24/2011 11:54 PM, Ilyes Gouta wrote:
> > Hi,
> >
> > I filed a bug:  https://bugzilla.redhat.com/show_bug.cgi?id=699263
> >
> > -Ilyes
>
> PackageKit isn't just a yum frontend and is likely to be integrated more
> and more with key components as we go forward.  If you aren't actively
> using the GNOME or KDE frontend, just remove those and leave the
>  framework as it is. 
>
> Rahul
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Rahul Sundaram]

On 04/25/2011 12:36 AM, Ilyes Gouta wrote:
>  Rahul,
>
>  > If you aren't actively using the GNOME or KDE frontend, just remove
>  those and leave the
>  > framework as it is.
>
>  That was tough :)
>
>  AFAIK (and I might be wrong) deep PacakgeKit integration wasn't
>  clearly mentioned in Fedora 15's feature set list. 
It isn't a feature that is driven by Fedora and hence it won't be in the
feature list.  It is just what happens when more upstream software take
advantage of it over time.. 

>  I was just asking if it was possible to recover to a situation where
>  the user would still have the choice, to use or not use PackageKit.
>  That's all. Fedora 14 gave that choice.
>
>  Alright, thanks for explaining! 
Just leave it installed.  You don't have to use it.  That is still a
choice. 

Rahul

[Ilyes Gouta]

Hi Rahul,

>  It isn't a feature that is driven by Fedora and hence it
> won't be in the
>  feature list.  It is just what happens when more upstream software take
>  advantage of it over time.. 
Yes, NOW it's clear! Thanks Rahul!

-Ilyes

On Sun, Apr 24, 2011 at 8:16 PM, Rahul Sundaram <metherid(a)gmail.com&gt; wrote:

> On 04/25/2011 12:36 AM, Ilyes Gouta wrote:
> > Rahul,
> >
> > > If you aren't actively using the GNOME or KDE frontend, just remove
> > those and leave the
> > > framework as it is.
> >
> > That was tough :)
> >
> > AFAIK (and I might be wrong) deep PacakgeKit integration wasn't
> > clearly mentioned in Fedora 15's feature set list.
>
>  It isn't a feature that is driven by Fedora and hence it
> won't be in the
>  feature list.  It is just what happens when more upstream software take
>  advantage of it over time.. 
>
> >
> > I was just asking if it was possible to recover to a situation where
> > the user would still have the choice, to use or not use PackageKit.
> > That's all. Fedora 14 gave that choice.
> >
> > Alright, thanks for explaining!
>
> Just leave it installed.  You don't have to use it.  That is still a
> choice.
>
> Rahul
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Richard W.M. Jones]

On Mon, Apr 25, 2011 at 12:25:16AM +0530, Rahul Sundaram wrote:
>  On 04/24/2011 11:54 PM, Ilyes Gouta wrote:
>  > Hi,
>  >
>  > I filed a bug:  https://bugzilla.redhat.com/show_bug.cgi?id=699263
>  >
>  > -Ilyes
>  
>  PackageKit isn't just a yum frontend and is likely to be integrated more
>  and more with key components as we go forward.  If you aren't actively
>  using the GNOME or KDE frontend, just remove those and leave the
>  framework as it is.  
PackageKit frequently *breaks* the yum command line, because it has
some unkillable (self-resurrecting) process that acquires a lock and
prevents yum from running.  It's a bug that we can't remove it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Rahul Sundaram]

On 04/25/2011 01:46 PM, Richard W.M. Jones wrote:
>  PackageKit frequently *breaks* the yum command line, because it has
>  some unkillable (self-resurrecting) process that acquires a lock and
>  prevents yum from running.  It's a bug that we can't remove it. 
You can edit the values in /etc/PackageKit/PackageKit.conf or remove
PackageKit-yum-plugin.  I have requested that the values be higher by
default but haven't managed to convince PackageKit developers.  If more
people complain about such issues instead of just removing it, we would
get a better default experience, I hope.

Rahul

[Matej Cepl]

Dne 25.4.2011 10:35, Rahul Sundaram napsal(a):
>  You can [...] remove PackageKit-yum-plugin. 
Unfortunately not ... it takes away (among other things bluez, 
control-center, gammu, gdm, gnome-bluetooth, orca, and gnome-shell).

Anybody any ideas how to get rid of it?

Best,

Matěj

[Ilyes Gouta]

Hi Matej,

Christoph Wickert provided an analysis in
https://bugzilla.redhat.com/show_bug.cgi?id=699263

-Ilyes

On Mon, Apr 25, 2011 at 8:19 PM, Matej Cepl <mcepl(a)redhat.com&gt; wrote:
>  Dne 25.4.2011 10:35, Rahul Sundaram napsal(a):
>  > You can [...] remove PackageKit-yum-plugin.
>
>  Unfortunately not ... it takes away (among other things bluez,
>  control-center, gammu, gdm, gnome-bluetooth, orca, and gnome-shell).
>
>  Anybody any ideas how to get rid of it?
>
>  Best,
>
>  Matěj
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Matej Cepl]

Dne 25.4.2011 21:26, Ilyes Gouta napsal(a):
>  Christoph Wickert provided an analysis in
>  https://bugzilla.redhat.com/show_bug.cgi?id=699263 
Which again lead to my broken gramophone song … we suck for not having 
Suggests/Recommends. Ceterum autem censeo, Carthaginem esse delendam.

Matěj

[Ilyes Gouta]

Hi Matěj,

>  Ceterum autem censeo, Carthaginem esse delendam. 

So this is Latin, what does it mean?

Btw, I'm from Tunisia (Tunis), the country of Carthage (historically) ;)

-Ilyes

On 26 avr. 2011, at 06:57, Matej Cepl <mcepl(a)redhat.com&gt; wrote:

>  Dne 25.4.2011 21:26, Ilyes Gouta napsal(a):
> > Christoph Wickert provided an analysis in
> > https://bugzilla.redhat.com/show_bug.cgi?id=699263
>  
>  Which again lead to my broken gramophone song … we suck for not having 
>  Suggests/Recommends. Ceterum autem censeo, Carthaginem esse delendam.
>  
>  Matěj
>  
>  -- 
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Michael Schwendt]

On Tue, 26 Apr 2011 08:11:20 +0100, IG wrote:

>  Hi Matěj,
>  
>  > Ceterum autem censeo, Carthaginem esse delendam.
>  
>  
>  So this is Latin, what does it mean? 
http://en.wikipedia.org/wiki/Carthago_delenda_est

Note that the translated meaning is less interesting than how this
phrase has been used.

[Matej Cepl]

Dne 26.4.2011 09:11, Ilyes Gouta napsal(a):
> > Ceterum autem censeo, Carthaginem esse delendam.
>
>
>  So this is Latin, what does it mean?
>
>  Btw, I'm from Tunisia (Tunis), the country of Carthage (historically) ;) 
http://en.wikipedia.org/wiki/Carthago_delenda_est ... it is used for 
somebody who is trying to force change and he isn't listened to for a 
long time.

Matěj

[Richard W.M. Jones]

On Tue, Apr 26, 2011 at 07:57:37AM +0200, Matej Cepl wrote:
>  Dne 25.4.2011 21:26, Ilyes Gouta napsal(a):
>  > Christoph Wickert provided an analysis in
>  > https://bugzilla.redhat.com/show_bug.cgi?id=699263
>  
>  Which again lead to my broken gramophone song … we suck for not having 
>  Suggests/Recommends. Ceterum autem censeo, Carthaginem esse delendam. 
+1 ... although it would also have to work the "rpm way" and not force
the user to make a choice at the point of installation.

A simple 'Recommends: <package list>', known about by RPM but
otherwise ignored by RPM, would allow tools that knew they were
talking to a real person to make a sensible list of recommendations
based on the packages the user already had installed or was about to
install.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Matej Cepl]

Dne 26.4.2011 09:36, Richard W.M. Jones napsal(a):
>  A simple 'Recommends:<package list>', known about by
> RPM but
>  otherwise ignored by RPM, would allow tools that knew they were
>  talking to a real person to make a sensible list of recommendations
>  based on the packages the user already had installed or was about to
>  install. 
There is no need for the user intervention ...

a) administrator of the system could set up in the configuration whether 
this is "lazy-user-desktop where I don't care about space and I want to 
have installed everything including a kitchen sink" or 
"tightly-kept-server where I want to know about reasons why there is 
every bit installed for space limits or security reasons".
b) administrator can remove packages which he doesn't want even without 
hosing his system (like the situation which happened here).

Matěj

[Daniel Mach]

Dne 26.4.2011 07:57, Matej Cepl napsal(a):
>  Dne 25.4.2011 21:26, Ilyes Gouta napsal(a):
> > Christoph Wickert provided an analysis in
> > https://bugzilla.redhat.com/show_bug.cgi?id=699263
>
>  Which again lead to my broken gramophone song … we suck for not having
>  Suggests/Recommends. Ceterum autem censeo, Carthaginem esse delendam.
>
>  Matěj
>  
Agreed.
 From my POV, RPM Requires should contain only deps which are *required* 
for a particular package. Suggests/Recommends is really missing and 
enforcing these kinds of deps via Requires is evil. What you should do 
now is to add such packages into a single comps group so they get 
installed together or create a meta-package that pulls all packages that 
*should* be installed together.

- daniel

[Kevin Kofler]

Daniel Mach wrote:
>   From my POV, RPM Requires should contain only deps which are
> *required*
>  for a particular package. Suggests/Recommends is really missing 
AIUI, Suggests/Recommends was almost accepted in rpm.org (BTW, rpm5.org has 
had it for ages), but the yum developers blocked it. :-/

IMHO we really need Suggests/Recommends support!

>  and enforcing these kinds of deps via Requires is evil. What you
> should do
>  now is to add such packages into a single comps group so they get
>  installed together or create a meta-package that pulls all packages that
>  *should* be installed together. 
The problem with comps is that it only works for new installs, not for 
upgrades.

        Kevin Kofler

[James Antill]

On Tue, 2011-04-26 at 15:31 +0200, Kevin Kofler wrote:
>  Daniel Mach wrote:
>  >  From my POV, RPM Requires should contain only deps which are *required*
>  > for a particular package. Suggests/Recommends is really missing
>  
>  AIUI, Suggests/Recommends was almost accepted in rpm.org (BTW, rpm5.org has 
>  had it for ages), but the yum developers blocked it. :-/ 
 You are misinformed.
 As far as I know "we" have never "blocked" any rpm feature.

 A suggests/recommends/etc. patch has been proposed to upstream rpm, but
was rejected.
 After discussion it seemed like it would be better to put that kind of
information in repo metadata, instead of the rpms directly. But it's
never been high enough on anybody's TODO to create a patch for that.

 Either of those approaches would only be a very low level of support
though, you'd then need to alter yum and yumex/etc to get any kind of
use out of it.

 Obviously if all you really care about is "install this for everyone,
but let people remove it again" (which is a lot of the suggests+
usage) ... you should be able to do that by adding things to a comps
group.

>  IMHO we really need Suggests/Recommends support!
>  
>  > and enforcing these kinds of deps via Requires is evil. What you should do
>  > now is to add such packages into a single comps group so they get
>  > installed together or create a meta-package that pulls all packages that
>  > *should* be installed together.
>  
>  The problem with comps is that it only works for new installs, not for 
>  upgrades. 
 I did a patch at the end of 2010 which changes that, but it's a
significant change. I might propose it again for F16.

 That also doesn't affect the above use case.

[Matej Cepl]

Dne 26.4.2011 15:31, Kevin Kofler napsal(a):
>  AIUI, Suggests/Recommends was almost accepted in rpm.org (BTW,
> rpm5.org has
>  had it for ages), but the yum developers blocked it. :-/ 
I have to defend Seth here ... in the last flamewar on this theme he 
admitted that introducing Suggests/Recommends would be question of half 
an hour (maybe he didn't mean it literally) and he would be willing to 
do it in the moment FESCO (or Board, or whoever is appropriate to make 
the decision) would tell him so.

Matěj

[Florian Festi]

On 04/26/2011 05:21 PM, Matej Cepl wrote:
>  Dne 26.4.2011 15:31, Kevin Kofler napsal(a):
> > AIUI, Suggests/Recommends was almost accepted in rpm.org (BTW, rpm5.org has
> > had it for ages), but the yum developers blocked it. :-/ 
Well, having
Suggests/Recommends in RPM only does buy you anything as 
RPM will just ignore them. Yum (or any other depsolver) has the job of 
selecting the "right" set of packages.
>  I have to defend Seth here ... in the last flamewar on this theme he
>  admitted that introducing Suggests/Recommends would be question of half
>  an hour (maybe he didn't mean it literally) and he would be willing to
>  do it in the moment FESCO (or Board, or whoever is appropriate to make
>  the decision) would tell him so 
I think if anybody can come up with a exact
description how they should 
look like and how they should work and can create some evidence that 
this is want we need and want implementing them is not the problem[*]. 
Until now no one has come up with a proposal and enough confidence.

As soon as one looks at the details it becomes less obvious what "we 
really want". Even whether the Suggests/Recommends should live in the 
packages or in comps or else where or both or both or in all three is 
still under debate. Do we need reverse relations? Do we really want to 
have exactly two levels of strength? Do we need "conditionals" (install 
an package only if two or more other packages are installed) as we had 
(have) in comps? Or should be trash the whole concept of comps and comps 
groups and start all over? When and how should they be evaluated? Do we 
need to save the users decision not to want the suggested package? What 
happens if the Suggests changes during an update?

If there really is some interest in getting any kind of weak 
requirements into yum and rpm answering the questions above is a first 
step (The list is not complete.) But from my perspective (as an RPM 
developer) "Fedora" has shown little interest in developing an own 
opinion about how the future of packaging and package handling should 
look like. So I am not too optimistic that we'll have Suggests or 
Recommends any time soon.

Florian

[*] Depending on the exact features implementing still can be tricky and 
require a lot of work. I doubt that it will be even remotely close to 
half an hour but nothing that cannot be handled.

[Adam Williamson]

On Tue, 2011-04-26 at 18:23 +0200, Florian Festi wrote:

>  > I have to defend Seth here ... in the last flamewar on this
> theme he
>  > admitted that introducing Suggests/Recommends would be question of half
>  > an hour (maybe he didn't mean it literally) and he would be willing to
>  > do it in the moment FESCO (or Board, or whoever is appropriate to make
>  > the decision) would tell him so 
>  I think if anybody can come up with a exact description how they
> should 
>  look like and how they should work and can create some evidence that 
>  this is want we need and want implementing them is not the problem[*]. 
>  Until now no one has come up with a proposal and enough confidence. 
Suggests: has been in Mandriva for several years, being used actively by
packagers and users, without any major problems. Yes, you can draw up
all kinds of theoretical objections and considerations, but to me the
fact of long-term practical usage rather seems to trump those. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Seth Vidal]

On Tue, 2011-04-26 at 09:57 -0700, Adam Williamson wrote:
>  On Tue, 2011-04-26 at 18:23 +0200, Florian Festi wrote:
>  
>  > > I have to defend Seth here ... in the last flamewar on this theme he
>  > > admitted that introducing Suggests/Recommends would be question of half
>  > > an hour (maybe he didn't mean it literally) and he would be willing to
>  > > do it in the moment FESCO (or Board, or whoever is appropriate to make
>  > > the decision) would tell him so
>  
>  > I think if anybody can come up with a exact description how they should 
>  > look like and how they should work and can create some evidence that 
>  > this is want we need and want implementing them is not the problem[*]. 
>  > Until now no one has come up with a proposal and enough confidence.
>  
>  Suggests: has been in Mandriva for several years, being used actively by
>  packagers and users, without any major problems. Yes, you can draw up
>  all kinds of theoretical objections and considerations, but to me the
>  fact of long-term practical usage rather seems to trump those. :) 

The implementation details into the pkg managers have been repeated
issues for all pkg managers that have them implemented.

We're not making it up for our health.

-sv

[Kevin Kofler]

Florian Festi wrote:
>  I think if anybody can come up with a exact description how they
> should
>  look like and how they should work and can create some evidence that
>  this is want we need and want implementing them is not the problem[*].
>  Until now no one has come up with a proposal and enough confidence. 
The proposal is this:

We would have 3 levels of dependencies:
Requires: = always required
Recommends: = required by default
Suggests: = not required by default

In yum, you would have 3 possible settings for "yum install/update" behavior 
wrt. soft dependencies:
1. Ignore all Recommends and Suggests.
2. Treat Recommends as Requires, ignore Suggests. (The default.)
3. Treat both Recommends and Suggests as Requires.
The setting would be set in yum.conf and could be overridden through a 
command-line argument, kinda like how --enablerepo works.

For "yum remove", you'd have 2 possible settings:
1. Ignore all soft dependencies during remove. (The default.)
2. Treat soft dependencies using the setting for install/update.
Again, the setting would be set in yum.conf and could be overridden through 
a command-line argument.
(The rationale for the proposed default is that it allows removing unwanted 
soft dependencies easily.)

In gnome-packagekit and KPackageKit, you'd have a dropdown in the settings 
to set the first yum option and a checkbox for the second.

The evidence that this is what we need: This is basically how all the 
existing implementations (deb, rpm5 etc.) I know of work and they've been 
found to work quite well for the distros using them.

Additional features such as conditional dependencies, reverse dependencies 
etc. might be useful too, but they're really orthogonal to this proposal.

        Kevin Kofler

[James Antill]

On Tue, 2011-04-26 at 19:23 +0200, Kevin Kofler wrote:
>  Florian Festi wrote:
>  > I think if anybody can come up with a exact description how they should
>  > look like and how they should work and can create some evidence that
>  > this is want we need and want implementing them is not the problem[*].
>  > Until now no one has come up with a proposal and enough confidence.
>  
>  The proposal is this: 
 Please read Florian's email again, and attempt to answer some/most of
the questions (a rationale for your answers might be nice too).
 It should have been obvious to you that a proposal like this would have
been discussed before.

>  We would have 3 levels of dependencies:
>  Requires: = always required
>  Recommends: = required by default
>  Suggests: = not required by default 
[...]
>  The evidence that this is what we need: This is basically how all the
>
>  existing implementations (deb, rpm5 etc.) I know of work and they've been 
>  found to work quite well for the distros using them. 
 rpm5 isn't used anywhere, so is irrelevant to any discussion on
anything.
 apt+aptitude+deb does use something like the above, with the very
significant differences of:

1. Debian with deb+apt packaging is vastly different to Fedora rpm+yum
packaging.

2. apt-get doesn't do anything, by default.

3. deb also has the two level reverse "soft requires".

4. If you talk to random debian people nobody knows why they have two
levels, what use it is over a single level (or, if it's really better,
why not three) ... and which level is signified by recommends or
suggests (or enhances/extends). Much like rpm/yum developers.

5. Even given #1, it's far from obvious that baking these assumptions
into the packages themselves is a win.

 SuSE with rpm+zypper does have recommends/suggests, and is "somewhat"
close to rpm+yum (kind of). But I don't know how much it is used ... and
I don't know what it's behaviour is. I also don't know what problems
they solve with it, and how well it solves them.

[Rahul Sundaram]

On 04/26/2011 11:25 PM, James Antill wrote:
>   SuSE with rpm+zypper does have recommends/suggests, and is
> "somewhat"
>  close to rpm+yum (kind of). But I don't know how much it is used ... and
>  I don't know what it's behaviour is. I also don't know what problems
>  they solve with it, and how well it solves them. 
It is possible to talk to them over email or IRC and get the details.  
Someone from Red Hat / RPM developer even presented in the openSUSE
conference the last time around. 

Rahul

[Adam Williamson]

On Tue, 2011-04-26 at 13:55 -0400, James Antill wrote:

>   rpm5 isn't used anywhere, so is irrelevant to any discussion on
>  anything. 
Since Mandriva and Mageia split, Per Oyvind got to be Mandriva's RPM
maintainer, and they have (not surprisingly) adopted RPM5. Not to say I
think it's a good idea, but there is one significant distro that now
officially uses RPM5.

>   SuSE with rpm+zypper does have recommends/suggests, and is
> "somewhat"
>  close to rpm+yum (kind of). But I don't know how much it is used ... and
>  I don't know what it's behaviour is. I also don't know what problems
>  they solve with it, and how well it solves them. 
Again, Mandriva has Suggests. This is how it works. Suggested
dependencies are pulled in by urpmi (MDV's high-level package manager)
unless you pass --no-suggests, in which case they aren't. The summary
output from an urpmi operation (where it shows you what's about to
happen before it actually happens) denotes packages that are suggested.
You can always remove a package which is only Suggested (not Required by
any other package). IIRC the behaviour of rpmdrake (the GUI manager) is
more or less the same, with an option for not installing suggested
packages by default.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Kevin Kofler]

James Antill wrote:
>   rpm5 isn't used anywhere, so is irrelevant to any discussion on
>  anything. 
It's used in PLD and Ark Linux, at least. (Ark Linux is Bernhard 
Rosenkränzer's project, the ex-RH-KDE-maintainer who has just as much a 
grudge against RH as RPM5's Jeff Johnson, so it's no wonder they went with 
RPM5.)

Please also note that my proposal is explicitly NOT to adopt RPM5 in Fedora. 
It is to adopt the concept of Recommends and Suggests, nothing else.

>  1. Debian with deb+apt packaging is vastly different to Fedora
> rpm+yum
>  packaging. 
That doesn't imply that soft dependencies wouldn't be just as useful to us.

>  2. apt-get doesn't do anything, by default. 
That's a bit strange, IMHO. (See also my answer to 4.)

>  3. deb also has the two level reverse "soft requires".
That could be discussed (and possibly implemented) later. There's no reason 
to block a decision on Recommends/Suggests on the reverse ones.

>  4. If you talk to random debian people nobody knows why they have
> two
>  levels, what use it is over a single level (or, if it's really better,
>  why not three) ... and which level is signified by recommends or
>  suggests (or enhances/extends). Much like rpm/yum developers. 
The idea of having 2 levels is that one would be enabled by default and the 
other one wouldn't. So the decision of which level to use is simple: Do we 
want to drag this dependency in by default (but still not make it a hard 
requirement) or not? Only 1 level is suboptimal because it doesn't allow 
making this decision (but it's still better than nothing, i.e. the status 
quo). With more than 2 levels, on the other hand, the level you assign to 
the dependency starts becoming pretty arbitrary, and there would be room for 
inconsistencies across the distribution. That's why my proposal has 2 
levels. And Debian's existing naming happens to fit those 2 levels nicely, 
even though their implementation doesn't exactly correspond to my proposal.

>  5. Even given #1, it's far from obvious that baking these
> assumptions
>  into the packages themselves is a win. 
Where else would you put them?

Comps? That has worse granularity (groups as opposed to packages) and 
doesn't currently work on upgrades (and I'm not convinced that the proposals 
to track comps groups as a kind of metapackages, which would make them work 
across upgrades, are a good idea).

Update metadata? How does the information get there? The metadata is 
normally generated from information in the packages or in Bodhi. The latter 
is not a solution because it doesn't cover packages in GA and because you 
don't want to have to reenter the soft dependencies each time you push an 
update. So this means the data needs to be in the packages (and the update 
metadata of course needs to carry it too, but it has to get it from the 
package headers, just like the hard dependencies).

        Kevin Kofler

[Genes MailLists]

On 04/26/2011 10:19 PM, Kevin Kofler wrote:
>  James Antill wrote: 

  There may well be plenty of good uses for such a soft dependency ..

  For example it sounds useful for R which has a hard depend on texlive
at the moment - but its only used for docs - so it would be way way
better to be a soft depends.

  Sounds reasonable to me (not a package expert just a user :-)

Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]

[Matej Cepl]

Dne 26.4.2011 18:23, Florian Festi napsal(a):
>  I think if anybody can come up with a exact description how they
> should
>  look like and how they should work and can create some evidence that
>  this is want we need and want implementing them is not the problem[*].
>  Until now no one has come up with a proposal and enough confidence. 
Well, I would for starters just take 
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps 
as a basis for the further refinement.

== Recommends ==

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together 
with this one in all but unusual installations.

== Suggests ==

This is used to declare that one package may be more useful with one or 
more others. Using this field tells the packaging system and the user 
that the listed packages are related to this one and can perhaps enhance 
its usefulness, but that installing this one without them is perfectly 
reasonable.

-----------------------------------------------------

As an examples of Recommends I heard crond (or procmail) and 
/usr/sbin/sendmail ... strictly speaking crond (and procmail) work 
without sendmail, but almost never seen the former without the latter, 
and usually if you want that it is some very special case, where 
administrator knows what he is doing.

On the other hand the case in the hand ... gnome-settings-daemon and 
packagekit (or phonon-gstreamer-backend and its packagekit plugin) would 
be Suggests — there are many real world scenarios where one could live 
without PackageKit, but there is no discussion that PK plugin (when it 
works, that is) could be very useful addition for totem or phonon.

>  As soon as one looks at the details it becomes less obvious what
> "we
>  really want". Even whether the Suggests/Recommends should live in the
>  packages or in comps or else where or both or both or in all three is
>  still under debate. 
IMHO, Suggests/Recommends should live in the spec file and be maintained 
by the package maintainers.

>  Do we need reverse relations? Do we really want to
>  have exactly two levels of strength? Do we need "conditionals" (install
>  an package only if two or more other packages are installed) as we had
>  (have) in comps? Or should be trash the whole concept of comps and comps
>  groups and start all over? When and how should they be evaluated? Do we
>  need to save the users decision not to want the suggested package? What
>  happens if the Suggests changes during an update? 
We can work on these more elaborate ideas later, but I think that the 
plain introduction of the Suggests/Recommends as outlined above 
(roughly, I guess there would be a lot of discussion about that even) 
would be nice starter for F16 (with a lot of bugs to discuss what level 
of dependency is required for each particular case). We can deal with 
the esoteric cases you suggest later.

And specifically about comps ... no, I would leave them in cases where 
they are useful (i.e., roughly anywhere they don't do work of S/R 
dependencies). They are useful for suggesting grouping of packages and 
organization of installation models (i.e., definition of what's Desktop, 
what's KDE, etc.). And even then I don't think there is a need for any 
rush to replace comps any time soon ... the biggest value of 
Suggests/Recommends IMHO is the possibility to break unnecessary 
Requires which make these nonsensical situations (i.e., you need 
PackageKit in order to have gdm).

>  So I am not too optimistic that we'll have Suggests or
>  Recommends any time soon. 
As I said above I have been saying this for almost five years already. 
It took Cato the Elder fifty years, so I think I have still some way to 
go :)

>  [*] Depending on the exact features implementing still can be tricky
> and
>  require a lot of work. I doubt that it will be even remotely close to
>  half an hour but nothing that cannot be handled. 
Of course, I expect that it was half an hour used in a Pickwickian manner.

Best,

Matěj

Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]

[Tim Lauridsen]

On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl <mcepl(a)redhat.com&gt; wrote:

>  Dne 26.4.2011 18:23, Florian Festi napsal(a):
>  > I think if anybody can come up with a exact description how they should
>  > look like and how they should work and can create some evidence that
>  > this is want we need and want implementing them is not the problem[*].
>  > Until now no one has come up with a proposal and enough confidence.
>
>  Well, I would for starters just take
>  http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
>  as a basis for the further refinement.
>
>  == Recommends ==
>
>  This declares a strong, but not absolute, dependency.
>
>  The Recommends field should list packages that would be found together
>  with this one in all but unusual installations.
>
>  == Suggests ==
>
>  This is used to declare that one package may be more useful with one or
>  more others. Using this field tells the packaging system and the user
>  that the listed packages are related to this one and can perhaps enhance
>  its usefulness, but that installing this one without them is perfectly
>  reasonable.
>
>  -----------------------------------------------------
>
>  As an examples of Recommends I heard crond (or procmail) and
>  /usr/sbin/sendmail ... strictly speaking crond (and procmail) work
>  without sendmail, but almost never seen the former without the latter,
>  and usually if you want that it is some very special case, where
>  administrator knows what he is doing.
>
>  On the other hand the case in the hand ... gnome-settings-daemon and
>  packagekit (or phonon-gstreamer-backend and its packagekit plugin) would
>  be Suggests — there are many real world scenarios where one could live
>  without PackageKit, but there is no discussion that PK plugin (when it
>  works, that is) could be very useful addition for totem or phonon.
>
>  > As soon as one looks at the details it becomes less obvious what "we
>  > really want". Even whether the Suggests/Recommends should live in the
>  > packages or in comps or else where or both or both or in all three is
>  > still under debate.
>
>  IMHO, Suggests/Recommends should live in the spec file and be maintained
>  by the package maintainers.
>
>  > Do we need reverse relations? Do we really want to
>  > have exactly two levels of strength? Do we need "conditionals" (install
>  > an package only if two or more other packages are installed) as we had
>  > (have) in comps? Or should be trash the whole concept of comps and comps
>  > groups and start all over? When and how should they be evaluated? Do we
>  > need to save the users decision not to want the suggested package? What
>  > happens if the Suggests changes during an update?
>
>  We can work on these more elaborate ideas later, but I think that the
>  plain introduction of the Suggests/Recommends as outlined above
>  (roughly, I guess there would be a lot of discussion about that even)
>  would be nice starter for F16 (with a lot of bugs to discuss what level
>  of dependency is required for each particular case). We can deal with
>  the esoteric cases you suggest later.
>
>  And specifically about comps ... no, I would leave them in cases where
>  they are useful (i.e., roughly anywhere they don't do work of S/R
>  dependencies). They are useful for suggesting grouping of packages and
>  organization of installation models (i.e., definition of what's Desktop,
>  what's KDE, etc.). And even then I don't think there is a need for any
>  rush to replace comps any time soon ... the biggest value of
>  Suggests/Recommends IMHO is the possibility to break unnecessary
>  Requires which make these nonsensical situations (i.e., you need
>  PackageKit in order to have gdm).
>
>  > So I am not too optimistic that we'll have Suggests or
>  > Recommends any time soon.
>
>  As I said above I have been saying this for almost five years already.
>  It took Cato the Elder fifty years, so I think I have still some way to
>  go :)
>
>  > [*] Depending on the exact features implementing still can be tricky and
>  > require a lot of work. I doubt that it will be even remotely close to
>  > half an hour but nothing that cannot be handled.
>
>  Of course, I expect that it was half an hour used in a Pickwickian manner.
>
>  Best,
>
>  Matěj
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 

The hard part is to define what the package tools should do in the different
cases
A depsolver need to work with real requirements, so it need to be defined in
what cases that a soft requirement will become a real requirements to do the
right thing
And 2 kind of soft deps don't make it more simple.
There is lot of actions you can do in a yum transaction :
install,update,remove,downgrade,obsolete,reinstall and you can mix them in a
single transaction so it gets very complex.

Another issue is that  Suggests/Recommends is a parent -> child relations
When having a package there supports some kind of plugin infrastructure, you
have to add recommends for all plugin packages, so each time a new plugin
package is added you have to change and rebuild the main package to have a
relationship, In that case it would be smarter to have a child -> parent
relationship, but that would be very hard to work with if stored in the
child spec only, you need some kind of central metadata to handle that.

Tim

Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]

[Kevin Kofler]

tim.lauridsen(a)gmail.com wrote:
>  The hard part is to define what the package tools should do in the
>  different cases
>  A depsolver need to work with real requirements, so it need to be defined
>  in what cases that a soft requirement will become a real requirements to
>  do the right thing 
See my proposal.

>  And 2 kind of soft deps don't make it more simple. 
See my reply to James Antill for why 2.

>  Another issue is that  Suggests/Recommends is a parent -> child
> relations
>  When having a package there supports some kind of plugin infrastructure,
>  you have to add recommends for all plugin packages, so each time a new
>  plugin package is added you have to change and rebuild the main package to
>  have a relationship, In that case it would be smarter to have a child ->
>  parent relationship, 
That can be discussed as a separate proposal later. Having reverse 
dependencies is not a requirement for having regular soft dependencies.

>  but that would be very hard to work with if stored in the child spec
> only,
>  you need some kind of central metadata to handle that. 
We already have such metadata: the repodata! Createrepo can extract that 
information from the child RPM and index it by the parent RPM name.

But again, we should get forward soft dependencies working first before we 
even start discussing reverse ones. It is obvious that the reverse case is 
more complicated, and there is no practical need for blocking the forward 
case on it.

        Kevin Kofler

Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]

[Stephen John Smoogen]

On Wed, Apr 27, 2011 at 12:47, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  tim.lauridsen(a)gmail.com wrote:
> > The hard part is to define what the package tools should do in the
> > different cases
> > A depsolver need to work with real requirements, so it need to be defined
> > in what cases that a soft requirement will become a real requirements to
> > do the right thing
>
>  See my proposal.
>  
My problem with your proposal is that it is not crazy enough. It is a
lot of work for marginal gain and doesn't really bet the farm enough.
I would prefer a proposal that Fedora 17 will be based off of Conary
or .debs as it is crazy enough to work.

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren

[Genes MailLists]

On 04/25/2011 04:35 AM, Rahul Sundaram wrote:
>  On 04/25/2011 01:46 PM, Richard W.M. Jones wrote:
> > PackageKit frequently *breaks* the yum command line, because it has
> > some unkillable (self-resurrecting) process that acquires a lock and
> > prevents yum from running.  It's a bug that we can't remove it.
>  
>  You can edit the values in /etc/PackageKit/PackageKit.conf or remove
>  PackageKit-yum-plugin.  I have requested that the values be higher by
>  default but haven't managed to convince PackageKit developers.  If more
>  people complain about such issues instead of just removing it, we would
>  get a better default experience, I hope.
>  
>  Rahul 

  Care to share which fields in there reduce the polling frequency ? I
did not see them.

  Say you wanted to make PackageKit check for updates once per day -
what would you change ?