Hi, > > I don't see how a layout standard can cover both the BSD and Linux > > worlds at the same time, unless it has variants. (And then there's > > Solaris and others.) > > We have an "annex" system, which supposedly splits out things that are > specific to a particular OS. There's only one annex, though (Linux), > and it seems that a lot of Linux-isms found their way into the main > document. > > It looks like the idea of describing all UNIXes was a goal more than a > fact. Given how easy it's been to find them with quick looks on the BSD > lists, it seems that no one took the bait. as I said, not only from the perspective of a BSD-user but even for the sake of the FHS, I think, one should make a Linux-specific FHS and declare is at such (as Thor Lancelot Simon pointed out). Finding the least common would end up in a very small base standard, even without many of the standard-paths used (e.g /usr/local). You would have many annexes for specific operating systems, making the standard large with many references and unreadable. What I like about the current FHS is: You can just read it, without looking at references or having to remember much. On the other hand, everything but Linux is more closed and tends to change things faster than Linux does. They would evolve faster than this standard. I don't see any good point in making a generic standard, documenting differences could be a nice hobby, but a plaintext file is imho not suitable for showing dependencies. As was pointed out, other OSes do not really care for the FHS as they have a more direct and conservative development which is on the one hand slower, on the other hand faster than it. Linux should have its own standard, making itself in its world more compatible across distributions instead of having a standard nobody likes (and uses?) because it is too large und unspecific. > > What would be really useful is a documented notion that all upstream > > packaegs should be configurable (at ./configure or equivalent time) to > > put various bits in various places, hopefully using standard directives, > > so that they can easily be configured to follow FHS on Linux or hier or > > hier_pkgsrc on BSDs. As a packager, the biggest problem related to this > > I run into is programs with hardcoded Linux assumptions (although many > > programs that use autoconf are easy to configure). > > I actually strongly agree with this. Even if you limit yourself to > Linux, there are changes and features that exist on one distribution but > not another. > > Do you maintain any documentation of "common Linux-isms" that hinder > porting to NetBSD? I suspect that the list would be good developer > documentation for more reasons than just porting. In my opinion, this is neither undocumented nor unknown. Good practices for programming are easy to find, even the single coding guidelines for NetBSD aim at portability. A problem I discovered lately is that Linux-(desktop-)developers intentionally break portage. Gnome, systemd, xfce, more and more projects are coding explicitly only for Linux. Whether they say it's easier, better, or that they don't have the manpower to make portable code - the result stays the same, it's simply ignorance of portability. I'm specially referring here to a talk I heard about the Gnome 3.0-release with the conclusion "We won't code for anything else but Linux because it is the future and the best one." Or: http://lwn.net/Articles/429597/ http://lwn.net/Articles/432914/ Anyway, this is clearly off-topic, but you have to consider this for understanding how the BSD-community looks at Linux. Regards, Julian
Attachment:
signature.asc
Description: PGP signature