IMHO Handbook should call "stub packages" like kde-base/kde "metapackages", as it better fitts their purpose. The only place where "stub package" occurs in docs is $URL (handbook/hb-working-portage.xml). KDE split ebuilds are complemented with "stub/meta" packages like kde-base/kde-meta, kde-base/kdepim-meta, not with kde-base/kdepim-stub :-). I could make a patch if the is enough interest. Comments?
I like the idea. I'll patch up hb-working-portage.xml for it, but this is just my opinion.
Just to clear any confusion....could someone be kind enough to explain : a) What are stub packages? b) What are meta packages? c) What's the difference b/w the two? if any. Thanks :)
Stub packages are packages that are kind of like symbolic links. An example would be typing "emerge gnome" or "emerge kde". There is no real 'gnome' or 'kde' to install, and the packages has very little, if any content but the purpose is to install the dependencies of the package to install the environment. Meta packages are a brand-new-name for these packages. For KDE, a "stub package", some of the deps are complemented with meta. Therein which, there is no difference.
I think there's no difference in the names, I just like the name "metapackage" more. Both of them referrs to some package which generally has no content, just dependencies.
note thate the developer handbook warns developers to not *DEPEND on "metapackages", and instead to depend only on specific libraries thus, i believe we should use metapackage for consistancy
Created attachment 58890 [details, diff] Patch changing stub packages to metapackages
since this section explicetly mentions kde, should we mention split ebuilds for kde? the "kde" package really isn't a metapackage, as it installs all of kde itself without pulling in all of kde's packages individually. kde-meta, on the other hand, seems to be. see http://www.gentoo.org/doc/en/kde-split-ebuilds.xml please correct me if i am wrong, as i don't use kde, but i am just remembering the guide...
I think that "metapackage" is the same as "stub package". Metapackage installs its dependencies and nothing else. It doesn't matter whether you talk about hierarchy under kde (kdelibs, kdeadmin,...), kde-meta (kdepim-meta, ...) or kdepim-meta (kontact, kmail,...). I think all those packages (not those in parentheses) could be considered metapackages.
I prefer "metapackage" as well
In CVS.
