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@thelounge.netwrote:

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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

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

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

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.

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

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

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.

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.

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

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.

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.

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

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.

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.

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 :-)

On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl mcepl@redhat.com 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@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

On Wed, Apr 27, 2011 at 12:47, Kevin Kofler kevin.kofler@chello.at wrote:

tim.lauridsen@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.