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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
