Vinay S Shastry wrote:
> On Wednesday 09 May 2007 6:39:41 am Essien Ita Essien wrote:
>> Strip ArchLinux down to a small tight Core that does one thing ONLY
>> ====================================================================
>>
>> I think we have *too* many packages in current and extra. I think we
>> ought to rethink the basics of Arch and look at it in the light of our
>> current scenario.
> <snip snip>
>> [gui-core] : users of this project, would have the _extreme_ minimal
>> stuff neccessary to get a gui system up and running. This would not have
>> any Window Manager specific packages, just the basic core, like Xorg,
>> dbus, hal, etc, - This one is goad oriented, and if careful design,
>> should be small enough to be also probably managed by the core team.
>>
>> [daemons]
>> This would be a category oriented project, that would be a catch all for
>> various contributed packages. postfix, sendmail, mail, mysql, postgres,
>> etc... all come in here. if over time, a group of ppl are highly
>> specialized on say mail or even specifically qmail, they can extract
>> themselves and their packages from [daemons] and start a [qmail] or
>> [mail] project. This wouldn't be under the care of the core team.
>>
>> [network-utils]
>> category for stuff like tcpdump, netcat, hping, ntop, etc.
>>
>> [development] : a category repo for various language compilers,
>> intepreters, etc... and then there would definitely be a need for
>> specialized groups like [python], [perl], [ruby], these would not be
>> under the care of the core team.
>>
>> [webframeworks]: need not be said, django, RoR, turbogears, cakephp,
>> codeigniter, you name it. And if some one starts a [django] well, enjoy.
>>
>> [gnome], [kde], [e17], [matchbox], etc would also exist here, maintained
>> by their various fanatic^H^H^H^H^Hs
>>
>> It should be noted that these repositories/projects would have
>> dependencies on others. for instance [gui-core] would need [base] and
>> any of [kde], [gnome], etc, would need [gui-core]
>
> This might sound awesome at first, but inter-dependency between packages in
> different repos could end up being a really big nuisance!
i see what you mean, though i was talking about stuff like: _any_
package in [gnome], would depend on the whole of [gui-core] being
installed or something of that nature. ofcourse, there's still stuff
like 'dsniff' would depend on 'libnids' which could be in the same repo
group for all we care.
>
> Actually, I'd suggest merging current and extra if possible.
This would help simplify things too, but the key would be to reduce to a
*small* core that is easily maintainable by a select few who will be
responsible for it... and the rest can be tossed up to ppl who are
interested in maintainign them. Just the way the kernel subsystem each
tie in back to the core via subsystem maintainers.
>
> The categorization that you mention is already done in the cvs repo layout
> (look at all the folders in the cvs tree).
right. I'm going out on a limb to suggest that they don't all don't
belong to the *core* developer's duties to maintain. If we move to a
Distributed SCM like mercurial, git, bazaar, etc, we can have the
official maintainers, pulling PKGBUILDS from trusted subsystem
(subproject) maintainers, who in turn are pulling from other sub sub
system trusteds. The tree, would then have a buildbot that builds the
packages which if the chain of trust is not abused, will be a no brainer
as they would all have passed. Bug fixes would now be passed to
subsystem ppls, just the way the kernel model works.
It feels bare and somewhat choatic, but that distributed model is the
actual strength of the whole system.
>
> Also, pacman could have an optional feature for 'labels' ('tags' in web2.0
> language) if really needed.
Now that's an interesting idea, and could be used instead of the hard
segmentation i'm suggesting, but then the tags groups would have
maintainers responsible for them (so amounts to the same thing?)
This system bears resemblance to the one on this thread:
http://www.mail-archive.com/[email protected]/msg10504.html
the difference is that the distibution heirachy is flat (which is not
really a bad idea), but would be hard to hold ppl responsible for
breaks, etc.
anyways... still hashing things around in my brain seeing looking for
good ideas.
cheers,
Essien
>
_______________________________________________
arch mailing list
[email protected]
http://archlinux.org/mailman/listinfo/arch
