On 1 August 2010 11:38, Ethan Grammatikidis <eeke...@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