On Ter, 2009-02-03 at 11:47 -0800, Donnie Berkholz wrote: > On 11:24 Tue 03 Feb , Donnie Berkholz wrote: > > > We currently provide an eclass and ebuilds arranged by top level > > > categories following upstream categorization. Explicitly gpe.eclass and > > > top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media > > > gpe-xsession. > > > We know we have a lot of them but upstream finds useful to classify them > > > like that and so do we. > > > > Could you expand on how each new category is useful?
In my maintainer point of view, it just make sense to follow upstream categorization of packages. In the user centric view, it will be a lot more easier to know what package is for by looking at each category. gpe-xxxx is intended for embedded devices, one might want to keep it clean and minimal. > > > > > The eclass and some ebuilds were based on bugzie #101393. We started > > > playing with them as big flat gpe-base category which evolved over time > > > by means of consecutive testing on ARMv5 handheld devices and needs. > > > > > > Since we are maintaining this over half a year now, we think that its > > > time to finally starting moving step-by-step the GPE suite into the > > > portage tree - starting with the eclass and toplevel categories. > > > > What are the stats on package count per category? > > I got this from solar: > > 30 gpe-base > 8 gpe-games > 4 gpe-media > 9 gpe-misc > 2 gpe-net > 32 gpe-phone > 6 gpe-pim > 18 gpe-utils > 8 gpe-xsession > > Unless those tiny ones are going to be growing a lot, I'm not terribly > convinced of this many new ones. > They won't grow much over time so I understand your point. Although, I would like to ask the drawbacks of adding those new categories to portage. Adding confusion and mess won't be an issue because these are very specific categories which won't affect other ebuilds or other categories. After all we don't want to introduce something like dev-gpe mail-gpe x11-gpe net-embedded ... which, IMHO, would be messy. So, despite "looking" a *lot* of new categories with not so much stuff inside, will this slow down portage sync/metadata-regen/loopkup in some way? Thank you, -- Angelo Arrifano <mik...@gentoo.org> Gentoo Linux ARM/OMAP850 Developer
