skalibs
Software
www.skarnet.org

What is that slashpackage convention and why are you recommending it ?

slashpackage is a convention proposed by DJB to have a reliable, cross-platform way of accessing files.

(Paul Jarc has a presentation of slashpackage that you may want to view.)

For instance, the execline package follows the slashpackage convention by default: this means that, among others, the execlineb binary can be found at /package/admin/execline/command/execlineb no matter the underlying installation, no matter the platform, no matter the OS - as long as the convention is followed.

This is a key point for system reliability. It is especially important for a script interpreter such as execlineb: people might distribute scripts, starting with a #! line, and if the shebang path is wrong on some machine, the script will break on that machine. Long story short: packages should be able to hardcode paths to other packages' components. The FHS alone does not guarantee this.

But the FHS is a widely adopted standard ! You cannot go against it !

This is irrelevant for two reasons:

  1. Standards are not sacred per se. Standards are nothing more than conventions. In the Unix world, there are two ways for something to become a standard: Guess what category the FHS belongs to. If you said the second one, you're right: the FHS is only a standard because people simply never bothered to question it and design anything better.
  2. Slashpackage does not conflict with the FHS, at all. You can have your clean FHS hierarchy, with the execlineb binary stored under /usr/bin or /usr/local/bin, and have it accessible as /package/admin/execline/command/execlineb, thanks to this wonderful Unix thing called a symbolic link. Slashpackage does not care where files are stored; it only requires them to be accessible via the /package hierarchy. So, why not have the best of both worlds, and respect the FHS and slashpackage ?

I disagree with your first point: the FHS is a good standard.

This is off-topic, but I'll address it here to be done with it.

Yes, of course there are good points in the FHS. The people who designed it in the first place were not idiots. However, this was a long time ago, and the problems that had to be solved then are mostly irrelevant now.

For instance, /usr was created so you could have a minimal system on a local disk, then mount /usr via NFS. Mass storage was a problem at the time, so it was easier and cheaper to only have one copy of /usr on an NFS server. Today, we have lots of cheap mass storage, and bootable CDs; the distinction between /bin and /usr/bin is largely irrelevant.

Same thing with /bin and /sbin. Why are some binaries stored under /sbin ? It's not to prevent the user from accessing them: /sbin is world-readable on practically every system. What is the benefit of having a separate /sbin for administrator programs, over just putting those in /bin, with a 0700 mode if one is paranoid ? This one is left as an exercise for the reader; but in any case, it does not make sense today.

The only filesystem hierarchy a modern system needs is the following:

The FHS addresses this constraints well enough, but due to historical legacy cruft, it does way more than is necessary, and it adds complexity.

The important point, though, is that there is ONE vital thing that the FHS does not do: ensure cross-platform accessibility of packages. I am not blaming the FHS: it was not designed to do that. But the need is there, and denying it only postpones the problems and makes life hard for users. Since the FHS cannot address the need, we need an additional convention. And slashpackage does the job.

We are a Unix distribution; our policy does not allow software to install anything outside of the FHS-defined directories. If it did, there would be chaos; we could not unify the software and make a polished distribution for the users.

I understand your point of view, but disagree with it. Please read this page about cross-platform compatibility.

In my opinion, the right way for a Unix distribution to package software is not to "unify" it and make a "polished" distribution. It's to friggin' package the software, i.e. provide a tarball and automatic installation, configuration and removal scripts.

By doing more than this, and especially by bypassing primary authors' decisions about how files should be accessed, Unix distributions are creating more work. More work for themselves, because they have to maintain subtly different versions of software than what the primary author provides; and more work for the users, because instead of learning "execline", a user now has to learn "Ubuntu execline", "Fedora execline", "OpenBSD execline".

Anyway, I have no objection to following the FHS. None at all. If you're going to package my software, you're free to put the files wherever you want. All I ask is that you do add symbolic links so files can be accessed via /package, and via /command too for executables. If your policy does not allow it, then I ask that you:

Be real. You're one of the two or three crackpots in the world who follow that convention. All you're going to achieve is deter people from using your software.

Well, I used to not care at all, because I mainly write software for myself, and quality - which includes reliability - is more important to me than widespread use. (Seriously, if widespread use was a good metric for quality, I'd be applying for a job at Microsoft.) After all, I'm rewriting the world, so let me do it my way, right ?

However, I have come to realize that unlike actual software, a convention is only good if it is followed by a non-negligible amount of people. The Unix world is certainly ready for better software, but it is apparently not ready for better filesystem organization.

So, starting in 2013, all skarnet.org releases now feature a way to build and install software on a non-slashpackage installation. I hope this will encourage more people to use it.

This means some responsibility has been transferred from the author to the packagers and the system administrators. If you are forfeiting the slashpackage guarantees, then it is up to you to make sure things work. In particular, you should pay attention to the following points:

But it's your dime.