On Tue, 03 Oct 2006 08:09:08 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > I have a list of all packages in the tree that currently use either > > of those functions[2]. If you maintain one of these packages, I'd > > especially appreciate your feedback. > > You missed games-* (yes, all of them) via the games.eclass, but I'm > sure there's a couple more eclasses that do user/group modification. Oops, I forgot to account for eclasses. I'll redo my script and run it again later to account for that. > What about applications that aren't tied to a profile? How do they > work? Well, user management is inherently tied to the userland which is being used, which is in turn tied to the profiles (default-linux, default-bsd, etc). Settings which are userland-agnostic (like default uids, member groups, GECOS comment fields), would be in the settings for the base/ profile. > Doesn't this increase the size of the profiles pretty > dramatically? I don't think it makes that much of a size difference. Most of this information is now duplicated over many enewuser/group lines in many different ebuilds. With this system, ebuilds just need to have a EUSERS and EGROUPS variable defined listing the users/groups needed. > Does it need to be tons and tons of small files, or can > we get away with a set of larger files with some sort of header? > > As you can see, this changes very little, but reduces the number of > small files in the portage tree. Is this necessary? Who knows? Will > it makes syncs slightly faster? Not a clue. I'm just throwing out an > idea. Hmm, parsing that would be a more difficult task for my scripts (which are just basic bash code doing some greps). Also, it seems like the many small files are easier to maintain. I don't know enough about rsync to know how it would affect efficiency, though. It's something I'll try and look into further. > Anyway, this looks really good. =] Thanks! -- Mike Kelly
signature.asc
Description: PGP signature
