comps discussion at fudcon and the future

[Casey Dahlin]

seth vidal wrote:
> On saturday at fudcon we had a small talk (meaning there were only 4 of
> us there: Jeroen, Jeremy, James, and Me) about the future of comps and
> what we need.
>
> We came up with a fairly radical departure that will take some work to
> implement and probably won't land for F11 but it is worth discussing a
> bit now. Please read through the whole thing before jumping all over it.
>
>
> Problems we see:
> - browsing packages is a difficult problem when you have 10000+ pkgs.
> - comps has a lot of meanings and it is not obvious what they all are/do
> - conditional pkgs (which provide a way of saying "install pkgX only 
>   if pkgY is installed) are several colors of doom b/c they aren't a 
>   dependency relationship and creates clutter on systems.
>   

Upstart has a similar dependency situation with services. One solution 
to this is to have packages that are "lazy-installed."

The relationship reads "install this package only if all of its 
dependencies are going to be installed anyway." In your example, pkgX 
would simply depend on pkgY, and be always installed, but "lazy." If 
pkgY is installed, pkgX gets installed, but if pkgY doesn't get 
installed pkgX won't get installed because it depends on pkgY, and 
dependencies may not be resolved strictly on pkgY's behalf.

Dunno that this is a /good idea/ in your case, but thought I'd coompare 
notes.

--CJD

> - users expect groups to be more persistent on their systems and to act
>   more like pkgs (ie: yum update should update groups, too)
> - optional/default/mandatory pkgs are confusing and not useful to most
>   people - the types are only useful when browsing, not when installing.
>
>
> We're still going to have a comps/groups file in the metadata but we'll
> be removing package types. If a package is a member of a group then
> that's it. It's in the group.
>
> When someone goes to install the group: 'yum groupinstall
> mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> comps/groups file from each repo, look if the group you're requesting is
> there. If so it will create a metapkg rpm (a package containing only
> requirements) on the packages that exist in the repositories that are
> listed in that group. Then it will depsolve and install that pkg. The
> package name will be @mygroup-of-fun. The package version will be a hash
> of the contents of the package along with a timestamp. It needs to be
> timestamp-based so the version is increasing so we can 'update' these
> pkgs.
>
> We'll make sure that yum knows about @pkgs to be looked up against the
> comps file (which should be  significantly smaller now).
>
> A yum update @mygroup-of-fun (or just a yum update) will grab the
> comps/groups file. Check to see if the hash has changed. If it has then
> it will create a new rpm and update it accordingly, pulling in the
> necessary deps as it goes.
>
> An additional feature return that this gets us is being able to have
> groups w/i groups.
>
> The reason we're building the packages on-demand instead of like any
> other pkg is that this allows us to merge comps/groups content from
> multiple repositories easily.
>
>
> We do suggest adding some new metadata (probably originating at the
> pkgdb) that will allow us to have keyword/tags for pkgs and ultimately
> tag-cloud browse them, if necessary. It will also afford us additional
> terms to search against for better search results.
>
> Fun, huh?
>
> There's a fair number more things to iron out and constructive and
> helpful remarks are welcome. :)
>
> -sv
>
>
>