Hi Ingo and Branden! On 7/24/22 16:57, Ingo Schwarze wrote: > P.S. > I moved this to the bottom because it is off-topic: > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: >> BTW, that's a thing I don't like at all from BSDs; IMO (and FHS's), > > Years ago, i tried to engage with the FHS maintainers, arguing that > FHS is for Unux-like systems in general, and trying to contribute > aspects relevant for *BSD. It was an uphill battle because the > FHS community was very firmly entrenched as "Linux only"; some > didn't even see a need to consider my comments at all, many > comments were rejected saying something like "this particular point > may be unusual on *BSD systems, but it is so important on Linux that > we cannot possibly allow the established *BSD convention for this > point in the FHS" even by those who were in principle willing to > view the FHS as a guideline for Unix-like systems in general. > > On top of that, the group was almost dead, much less active than > for example the groff community, and even that is a very small group. > So ultimately, i gave up and left. Other OpenBSD developers laughed > at me for even trying, essentially saying "Why do you even care > about that Linux-only crap?" I still disagree and believe a > file system hierarchy standard for Unix-like systems could potentially > be useful. Just consider that "Where are the URW fonts?"-saga > currently under way on this list as an example.That you very much for your attempts to make the FHS be a real Unix standard. It's sad to read this.
> > But dismissing decade-old *BSD standards like the use of /usr/ > for the base system and /usr/local/ for packages as a standard > violation, and promoting /opt/ which is firmly a Linux-only > invention, is not going to help.As Branden noted, this wasn't a Linux thing (I don't have the background he has, but I researched a lot about this, and found something like that).
> >> /usr/local is for sysadmins to build from source; > > Doing that is *very* strongly discouraged on OpenBSD.I guess that's why the directory was reused in the BSDs to install ports (probably ports were installed by the sysadmin there, and by extension, ports are now always installed there, but that's just a guess).
> If you only want > to try out some unported software, do not install it at all or install > it in your home directory. If you are serious about providing something > system-wide, you are strongly expected to create a port, even if you do > not publish the port, so it can be properly installed, kept track of > by the package tools, controlled for collisions by the package > tools, and cleanly uninstalled when its time comes. My use case is the following:As a programmer, I want to provide a reliable and useful Makefile (I know that's a rare thing to do, but I like to debug and optimize my Makefiles, both for performance and user experience, as we've already discussed).
So, packagers/users should be able to pick a project of mine, and trust the Makefile to produce a good installation, even in parallel (as good as a Makefile can do, that is).
I also want to test that my programs, when installed in the system, behave as expected, and that's one of the reasons I debug my programs by installing them, and running as a normal user would run them. Running in ~/bin is not the exact same thing as the system, and may not uncover some bugs.
So, I run `make install` several times a minute sometimes when programming (or when writing manual pages).
It also has the extra benefit that all of the paths are already configured by default, so I can omit paths (or skip configuring my user's PATH to include things like ~/bin and MANPATH to include ~/share/man).
> > Creating a package is really simple. Just a few days ago, senior > ports developers provided help to a user on our lists to do it > properly for company-internal software that will never be published, > and the thread was short because there wasn't that much to explain. I don't know how easy it is to create a port. > > I did build RPMs for SLES at one point in the past when working > for a company, and i dimly remember looking at debian package build > documentation occasionally, and both seemed significantly harder > to both get started with and to master than BSD ports, so Linux > users may have a stronger motivation to just "make install". > Then again, there may also be a slight bias at work, what you are > used to always feels simpler than what you are less familiar with.But certainly, Linux packages are _hard_. I tried packaging for debian several projects of mine, and I always gave up. I have a list of things to read/watch for my next attempt, but I'm very lazy about it, since none of my previous attempts were good enough for my taste.
> > In any case, it is very intentional that OpenBSD does *not* provide > a directory to users that they can "make install" to. >That's sad, but more sad is that BSDs took an existing path (/usr/local) to a different purpose. I had a discussion in NGINX Unit about it, and the decission for now has been: "support prefix=/usr/local for default manual installation through the Makefile, and let BSD users adjust to their preferred path". We were concerned that we might get collisions with the BSD port also installing in /usr/local, but that's the least evil (and considering BSD users don't typically run `make install`, it's not so bad).
>> optional _packages_ should go to /opt). > > Not even Debian adheres to that. When i install an additional, > optional package, i.e. one that Debian did not install by default when > the system was originally installed, most of the time, that optional > package goes to /usr/, not to /opt/.Yeah. Since the line between optional and non-optional software is not so clear, some people have considered optional packages to be those that you install manually (i.e., .deb packages downloaded manually). So /opt has become the /usr/local of .deb packages.
On 7/24/22 17:44, G. Branden Robinson wrote:
At 2022-07-24T16:57:19+0200, Ingo Schwarze wrote:But dismissing decade-old *BSD standards like the use of /usr/ for the base system and /usr/local/ for packages as a standard violation, and promoting /opt/ which is firmly a Linux-only invention,Oh, no it's not. I remember that thing from Solaris 2.3 or 2.4. Here's a slightly later source. https://docs.oracle.com/cd/E19455-01/805-6331/fsadm-17/index.html [Branden's long rant about corporations, and NGOs]
I agree with the rant.BTW, I have a longstanding issue with Debian packages. Branden, your experience with Debian might help, if you find some time.
The thing is: I'd like to provide an official Debian package of the man-pages. There are several reasons for that:
- Be able to use the full power of dpkg(1) to manage the installed files (`make install` is quite weak there).
- Show users a good example of how to package their small programs, with the minimal stuff (but I aim to do it of very high quality).
- Make it easier for users to install the pages directly from upstream, especially now that we haven't released in a year. (They can already `make install`, but that's not perfect, since they likely want dpkg(1) to manage the files. I know there are tools to autogenerate a package while installing with `make install`, but the quality of such packages is not something that I like.)
- I only want to provide a .deb, for reasons related to your rant.So I'd like to provide a `make pkg-deb` target to create the package. Would you mind helping me do that?
Cheers, Alex -- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
