[pacman-dev] pacman packaging

[Roman Kyrylych]

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 (Роман Кирилич)