comps discussion at fudcon and the future

Matthew Woehlke mw_triad at users.sourceforge.net
Wed Jan 14 21:40:23 UTC 2009


seth vidal wrote:
> On Wed, 2009-01-14 at 15:22 -0600, Matthew Woehlke wrote:
>> No. I want to update everything currently installed, and be /offered/ 
>> anything new. By "new packages" I mean "packages that didn't exist last 
>> time I ran updates" (as opposed to "updates of already installed 
>> packages"). Sorry for the confusion.
> 
> Well having them 'offered' implies interactivity in a way that I very
> much doubt we'll have. If the group has new pkgs in it then those are
> requirements, not recommendations.
> 
> It sounds like what you want is a better way of searching out
> packages and installing the specific ones you want.

They are only dependencies if I have a metapackage installed. Hence why 
I suggested something like a "subscription". IOW, not a metapackage, but 
something that would tell me about new (i.e. didn't exist before) 
packages. I'm not sure that qualifies as "searching" per se; the idea 
was for such new packages to be reported along with update reports.

This would be easy* in PK; just list new stuff as "new" when listing 
what updates are available. Either the user installs them or not, and PK 
keeps track of what the user chose not to install and doesn't offer them 
again as "new" (they'd still be there if you went through the normal 
"install something I don't have already" process, of course).

For yum it would be harder. I think I would want them to show up in 
'update' and 'check-update' until the user issues some new command, say 
'yum clear-optional-updates', which would make yum stop offering any 
packages that are "new" as of when the command is run.

(* by "easy" I mean to come up with a design that is sensible to the 
user, not that the code would necessarily be easy)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane




More information about the fedora-devel-list mailing list