Re: [dev] How about sta.li ?

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

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

>
> On Jul 31, 2010, at 11:10 PM, Jens Staal <staal1978_AT_gmail.com> wrote:
>
>> Another, sort of related question: how has it worked out with the
>> static binaries of 9base etc built with bionic?
>>
>> I was thinking, perhaps a "static binary repository" could be a
>> good start :)
>>
>> 2010/7/31 Anselm R Garbe <garbeam_AT_gmail.com>:
>>> Hi Krankkatze,
>>>
>>> On 31 July 2010 19:43, Krankkatze <krankkatze_AT_gmail.com> wrote:
>>>> I'm very interested in the sta.li project and would like to know
>>>> if the
>>>> project is still active or not, and if any help could be brought.
>>>> Thanks!
>>>
>>> It's inactive atm, but I did plenty work in the sta.li area that is
>>> still unpublished, also because I did some sort of it at work.
>>> I plan to resolve the issues during the next weeks and will
>>> provide an
>>> update by then.
>>>
>>> Help is definitely welcome, particularly in the area of patching
>>> ld in
>>> order to produce static libraries when shared objects are
>>> requested in
>>> a tee-like fashion and to statically link executables when shared
>>> objects are supplied. I started some ld patches a while ago, but
>>> they
>>> are half way, but I'm happy to provide them on request.
>>>
>>> HTH,
>>> Anselm
>>>
>>>
>>
>
Received on Sun Aug 01 2010 - 12:38:14 CEST