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

Re: Agenda for the 2009-05-26 Packaging Committee meeting



José Matos wrote:
On Wednesday 27 May 2009 17:23:33 Adam Williamson wrote:
Well, yeah, I actually noted in my email that MDV's tool does exactly
that (well, it doesn't show them as separate sets, it shows them in one
long list with "(suggests)" to note the suggested ones. But doing it in
sets would, I imagine, be trivial).

...and consistent with how yum currently works.

Wishful thinking. :-)

Why?

It is easy to come with an example where those sets overlap, i.e. there is one package that only shows as (suggests) in more than one package.

Sure. Why does that matter?

So I am not sure if it is worth the trouble to show all the separate sets.

How else are you going to display things? Specifically how are you going to display things that isn't /broken/? We have two groups right now, 'updating' and 'installing for dependencies'. Putting packages pulled in (only; directly or indirectly) by suggests: into either of those is clearly wrong.

I don't see why this is hard. I do 'yum update'. It wants (with suggests: feature) to install packages for any combination of three reasons:

- package is installed and is being updated
- package is required by some package in transaction
- package is suggested by some package in transaction

(Without suggests: feature you only have first two.)

Any package may belong to all three states, true. However it is placed in the group with the "strongest" reason for it being in the transaction. (The above are listed from strongest to weakest.)

If it's installed already, set "required" flag and "update" flag. If it was required by something, set "required" flag iff what required it has "required" flag. Packages with "update" go in 'updating' group, with "required" but not "update" in 'installing for dependencies', everything else in 'installing for suggestions'.

How hard is that, really?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Sorry, but I can't look into that right now. I'm running low on sacrificial chickens.


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