Re: [dev] How about sta.li ?

On 1 August 2010 11:38, Ethan Grammatikidis <eekee57_AT_fastmail.fm> wrote:
> On 1 Aug 2010, at 8:43, pancake wrote:
>
>> I want to say that in latest glibc (see archlinux) many 9base programs
>> cant be executed because of being static.
>>
>> Compiling bionic would be great but I was unAble to workaround their
>> makefiles to do it without the android sdk.
>>
>> Glibc must be avoided as much as possible. Anybody working w bionic here?
>
> Agreed, but what about other libcs? I'm astonished glibc has come up at all.
> Is dietlibc really that inadequate? Or uclibc? I brought up dietlibc first
> because as far as I know it doesn't even have dynamic linking. If it is
> missing necessary features, perhaps it might even be easier to add those
> features than to bring glibc to heel.

I think fefe's C skills and coding styles are a bit over-rated,
probably because of his popularity as conspiracy theologists in the
German hacker scene. The dietlibc code is not as clean as uclibc's
code imo, though of course a hell lot saner than glibc which isn't a
big achievement.

>> 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.

Some tools are using dl{open,sym,close} to support a certain kind of
modularity, including x.org. We have to live with those few
exceptions.

>> 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.
>
> 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.
>
> #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?
>
> #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.
>
> #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 wised up. I no longer expect digital dinosaurs to work with a few
> commands or clicks unless teams of people were paid to tame them.

As said earlier, I don't think any kind of package management/system
is needed apart from hg or rsync.

Cheers,
Anselm
Received on Sun Aug 01 2010 - 20:39:45 CEST