Re: [dev] How about sta.li ?

Well, maybe not libdeps in stali, but surely bindeps, dwm depends
optionally on dmenu, mutt in vim, etc.. Some of them are optional, and
other ones are mandatory. I would call them roles or metapkgs.

Adding and removing lines in files surely sucks in automatic scripts
because if u modify the file by hand it may fail or break the syntax.

I would prefer if each service can own their own files and the pkg
system should notify and not remove the modified files.

Checksumming is IMHO an important part of the pkg system, not only for
this. Reason, also for security.

About users and so. IMHO is an admin task and if you want to keep some
cntrol on the system always requires a bit of interaction and keeping
track which pkgs use which users.

Having general users on the base system for most common tasks and
letting the admin choose the users/groups used by every nonstandard
service would be enought.

In fact we can keep track of users and groups by using a ref/unref
model binding each extra user to a pkg ( notsystem ones) this way the
system automatically wipes the users and groups when not used... But
certainly.. I hate such automatisms because sometimes can break things
you don't expect, so it will be better to just notify.

But installing stuff should never be interactive.

On Aug 1, 2010, at 12:38 PM, 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 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 tarbal
>> ls)
>>
>> 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 Mon Aug 02 2010 - 11:47:37 CEST