good point, but then I think there needs to be an aur-utils package, even if it's left in testing or some other infrequently used repo. On 1/9/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/1/9, Christ Schlacta <aarcane@gmail.com>:
I'd have to say that when presented in that manner, I agree that unnesecary splits seem bad.
it's a tough issue. on one hand, we could split, but then a user would have to think more. may need a utility and not have it.
on the other hand, if we don't split, there are more binaries on a system, and that means more chance for a user to break something.
then again, if an arch user breaks something, it's his or her own fault, since we don't claim to be an entry level distro.
then again since we're not an entry level distro, we should give a little more thought to security, and system performance, IE not over-crowding the system, etc.
there are alot of pros and cons for each way. however, I have to say this: if we split, then aurbuild needs to be included in pacman-utils, or at least in a package (like aur-utils or something) of it's own.
I was thinking about pacman split for a long time, but my point is a bit different. I think split should be done at the same time with gcc->libgcc move. Most packages doesn't need full gcc to run. Splitting making all those packages to depend on libgcc (or remove glibc and gcc deps at all as they are in base install anyway) will allow to have more clean system for those who doesn't ever compile anything. No automake/autoconf/etc. Then only pacman-utils (makepkg, abs, versionpkg, srcpac etc.) should depend on full gcc, while pacman will not require it, of course. That's how I see this.
About aurbuild and other AUR tools - they should not be part of pacman-utils because they may and will change independently of other pacman utils as they depend on AUR changes.
-- Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev