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. - 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
