[pacman-dev] pacman packaging

[Christ Schlacta]

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
> http://www.archlinux.org/mailman/listinfo/pacman-dev
>