I've always believed that the filesystem itself should be used as a packaging system... This is EXACTLY what I want to do. Each package is its own FHS... Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 3 December 2013 20:44, Laurent Bercot wrote: > > One problem I'd like to solve is making a way for users to override >> the system resolv.conf; >> > > The s6-dns client library uses the DNSCACHEIP environment variable for > this: if it contains a list of DNS caches, this list will override the > /etc/resolv.conf-provided one. (The idea comes from djbdns, but has been > extended to a full list instead of a single cache address.) > Same thing with the DNSQUALIFY environment variable, which can have > a list of suffixes that overrides resolv.conf. (djbdns had a complex > rules-rewriting-based qualification mechanism that nobody ever used, > so the simpler approach was easier and better.) > > Maybe musl could use the same approach: environment variables are a > reasonable place for hardcoded-path overrides. But it has to be balanced > against namespace pollution. > > > > This seems like a good foundation for a package system. I've looked >> into Nixos before but never really tried it out, and got the >> impression that the concept was very good but it might not be the best >> implementation. So something similar to Nixos sounds interesting. :-) >> > > I've always believed that the filesystem itself should be used as a > packaging system: every package should have its own system user and reside > in its own directory, and /usr/bin and friends should only contain > symlinks. Native isolation via Unix permissions, atomic package > replacement, > easy package management. But for some reason, people seem absolutely > reluctant to do this. > > > > The philosophy used in musl, which is somewhat different from the sort >> of philosophy you might have when designing a new distribution, is not >> to invent new policy but to avoid policy and build on existing, >> already-widely-accepteed policy when it's unavoidable. >> > > I don't agree with all decisions in musl, but this one I can definitely > stand for. > > > > There are LOTS of ways one could extend hostname lookups, ranging from >> NSS modules to >> hosts.d and resolv.d, but rather than trying to support everything >> imaginable (result: bloat and serious security considerations) in >> libc, the musl approach to hostname lookup is that libc contains the >> basics that are suitable for most/all simple systems, and anything >> more advances can be provided by an external daemon running on >> localhost that speaks DNS protocol and provides whatever lookup >> semantics you desire. >> > > In the DNS case, the flexible - and best, IMNSHO - approach is to run a > small local DNS cache on localhost indeed; but the problem is that there's > an existing codebase that sometimes insists on clobbering /etc/resolv.conf, > which adds to the packaging burden when your purpose is to create or > maintain > a distribution. Having extension mechanisms at the libc level can help in > that situation. > > -- > Laurent > >