[pacman-dev] pacman packaging
aarcane at gmail.com
Tue Jan 9 21:39:02 EST 2007
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 at gmail.com> wrote:
> 2007/1/9, Christ Schlacta <aarcane at 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 at archlinux.org
More information about the pacman-dev