Poll about package management

[Alexander E. Patrakov]

Greg Schafer wrote:
> Alexander E. Patrakov wrote:
>> does it
>> allow running arbitrary scripts on the DESTDIR contents before
>> actually creating a package?
> 
> Um, I don't think so. However, while Pacman itself is written in C, the
> "makepkg" portion of the system is a Bash script which allows easy
> hackability. That's what allowed Alex Merry to write the fake_install()
> patch that I still use today.

I.e., writing such patch would be easy. That's enough.

> While I'm a Pacman fan, it is by no means a perfect PM. It uses an
> ASCII text package database which tends to slow down when you have a
> zillion packages installed.

The same applies to dpkg.

> It probably won't do everything you want, like
> easy splitting off of -devel and runtime packages.

How does Arch Linux handle library transitions then? E.g., suppose that a new 
version of OpenSSL appear that builds libssl.so.0.9.9. How do they avoid the 
situation that some of the binary packages (those not yet rebuilt) want the old 
libssl library?

> You seem to be striving for perfection. When I want all the bells and
> whistles I run a mainstream distro.

Without this, LFS is unsuitable for production use. Nevertheless, people want 
it. There are only two ways to deal with this situation: make LFS work 
perfectly, or drive them away from LFS even before they think about it in 
production. So, we are back at the old dilemma about LFS-course (that has to be 
simple and fully understandable by everyone, possibly even oversimplified, and 
it is not a bug that it doesn't work for a significant portion of users) vs 
LFS-distro (that also has to be present, just to show the shortcomings of 
LFS-course as a distro).

> It is simply too labour intensive to
> have "the lot" on a self built system. I looked at the amount of effort
> Dan has apparently put into his RPM based system and weeped :-(  Pacman is
> good enough for my meagre needs, but I wouldn't use it if, for example, I
> was trying to be the next Ubuntu.

Here I fully agree.

-- 
Alexander E. Patrakov