Re: [dev] How about sta.li ?

On Sun, 1 Aug 2010 11:38:14 +0100
Ethan Grammatikidis <eekee57_AT_fastmail.fm> wrote:

> On 1 Aug 2010, at 8:43, pancake wrote:

> > I wrote slpm which can be used as template for binary and src
> > packages and it supports static compilation. A repo of bins for it
> > can be good. Packages aré pretty similar to slackware (mere tarballs)
> >
> > I know that stali aims to not have package system, but. Imho slpm
> > can be a good start to generate chroots or manage binary packages in
> > a simple way. It needs more work coz bindeps are not supported, etc..
>
> Bindeps as such won't be relevant to a statically linked distro,
> although there will be a few run-time deps here and there, which will
> typically be looser than binary library deps need to be.

Those should be handled using the same mechanism in the package
manager. Don't forget about dependencies of rc scripts on system
commands.

> > So imho binpkgs for stali should just be tarballs u uncompress or
> > you remove. But pkgsystem is a complex topic because many progrMs
> > require postinstall scripts and others which really suck by nature
> > and I would love to erradicate all this innecesary complexity or
> > just avoid using them.

Unfortunately, some packages that we need to tolerate (at least for a
while) require that when other packages are installed, certain of their
files are modified, and unfortunately, {pre,post}{{,un}install,upgrade}
scripts are the simplest way for the package manager to support such
packages.

> How many packages really require post-install scripts any more? Makes
> me wish I still had Source Mage grimoires handy so I could ls */*/
> POST_INSTALL, but I suspect most post install scripts do one or more
> of these 4 things:
>
> #1: The script does things which are arguably the sysadmin's
> responsibility. These could be dropped, at the expense of making life
> miserable for lazy owner-admins such as myself.[*] :-) This category
> could perhaps cover the other cases.

To quote Ethan Grammatikidis (i.e. you):

| Do not specify what the computer should do for you, ask what the
| computer can do for you.

Why the change of heart?

> #2: The script adds users and groups to /etc/passwd and /etc/group.
> There's no pressing need to reverse this on uninstall, and honestly
> passwd and group could come pre-filled with all the admin accounts you
> might ever want. Some master record of system user and group IDs must
> exist so the numbers don't conflict. Why not distribute this master
> record?

Why would the UID/GID numbers need to not conflict on different
systems? 9P and tar identify users and groups by name.

> #3: The script sets ownership of some files or dirs, likely under /
> var. Tar when run as root is quite capable of preserving the ownership
> and permissions of the files it extracts, so this is a non-issue.

Configuration file permissions can be important, too.

> #4: The script adds lines to some other file. I can't imagine what
> might still need this except BSD-style init or some old-fashioned
> cron, and in both cases the final installation could or perhaps should
> be left to the sysadmin.

I've run into GNU info's ‘dir’, fontconfig's caches, and the GHC
package database. Of those, the flakiest one on Arch has been the GHC
database, because pacman can install packages before their
dependencies; the info ‘dir’ was the flakiest cache on Fedora.

The simplest non-awful way to handle these cases is to run a script
when the contents of certain directories are changed. This doesn't
happen now because it requires more complexity in the package manager,
where it would need to be implemented, even though it would result in a
simpler system overall.

Robert Ransom