@Dekken the idea with these tools is that you should have Android-esque app stores where developers push their packages directly, so all your apps, from text editor and terminal emulator, to IDE and web browser, to games, is installed as flatpak/etc app from the software vendor, completely bypassing the distro.

@kurisu yeah, we don't need another app store full of throwaway apps and malware.

@kurisu well some users probably do. I guess it's better to have them use Ubuntu with flatpak than to have them use Windoze with setup.exe-s.

Because then instead of "jeez you srsly want me to use that windoze-only app?" I'll have to deal with "jeez you srsly want me to use that flatpak app which is nicely sandboxed by default", which'd probably be much less of a nuissance.

@kurisu there's also GOG. Which... apparently... ships self-extracting shell scripts that extract a game directory with a lib/ subdirectory with a handful (47) of .so libs.

@enkiv2 Right now I have 900 package sinstalled on my Arch laptop.
I can't imagine how I could possibly review each of them for quality and malice, figure out the build flags, and then keep track of the updates.
Also, most of my strong opinions align with those of Arch maintainers. Some don't. But I don't mind. For me it has the best cost/benefit ratio I've seen so far.

@Wolf480pl I've had a basically poor experience with Arch, because Arch maintainers have major philosophical differences with me. Likewise, Debian (though Debian's package management renders my system unusable less often than Arch's). I prefer Lunar, on the grounds that Lunar is more hands-off: maintainers tell the package system about dependencies but do not write patches (and really are just approving user submissions of package info)

@enkiv2 Arch also has a very strict policy against patching. Most of the time they only set ./configure options, and sometimes patch in a missing DESTDIR to the makefile, because duh, you need to make install into the dir that will be tar.gz-ed and not into filesystem root...

@Wolf480pl In the case of Lunar, the policy is: we do not patch files at all, nor do we take bug reports for packages other than the package manager, nor do we host any files ourselves (though we may mirror third-party patches submitted to us or mirror extremely important packages that are part of the base image of an installer), nor do we support binary packages at all (with the exception of the installer livecd).

@Wolf480pl It is refreshingly minimal, and appeals to me as someone who would rather spend effort writing my own patches for software than spend effort trying to understand how a maintainer decided to change some package.

@Wolf480pl the source-only, upstream-only policy avoids the issues that have sunk my arch installs (like a minor version upgrade to ncurses breaking pacman).

@enkiv2 what does the package manager do? Is it like gentoo's portage, i.e. builds backages from source based on a recipe provided by the distro?

@Wolf480pl
It's like that, though it's a lot simpler (both in terms of code, conceptually, and in terms of ease of use) than portage.

I recommend installing lunar on a spare machine & reading the source code of the package manager. It's a couple hundred lines of clean shell script. It's evidence that most of the complexity involved in existing package managers is an artifact of poor initial design work.

@enkiv2
>spare machine
I don't have such a thing, sorry.

Anyway, who decides what ./configure options (like prefix or bindir/libdir) to use for each packge?

@Wolf480pl
You seem to be assuming the package manager is a lot more elaborate than it really is.

The lunar package manager runs wget to download tarballs, extracts those tarballs to a build directory, and runs a normal build (unless overridden by the package info). It will apply patches if they are listed, and check checksums if they are listed.

Dependencies are listed in the package info file, which is a shell script setting environment variables.

@Wolf480pl
Optional dependencies (with support enabled or disabled by configure) are prompted for, with the default being yes for already-installed packages and no for uninstalled packages.

Dependencies that could be met by several different packages default to the one that is already installed, or barring that, the first listed.

(In other words, basic sensible choices.)

@Wolf480pl
Submitting a package is done through a small shell script that cats the package file content into a text file. It used to post that text file to a mailing list, but now it submits it to a web service that posts it to the mailing list.

Maintainers decide whether or not to accept it, with the general policy being to prefer to be as close as possible to a normal build. (In other words: unpack, cd, ./configure ; make ; sudo make install)

@enkiv2
No, I'm not assuming that it is elaborate.

My question still holds:
Does the package info file contain options to the upstream's build scripts, such as options that tell the build script where to install binaries, libraries, and other files?

@Wolf480pl
It can, if you like. After all, you can stick anything in any environment variable in a package info file.

It's considered desirable to minimize such customizations on the distro level, instead letting the user specify them if they want.

By default, it will install to the package's default prefix. That is emblematic of the policy as a whole. The only time that would be overridden globally is the rare situation when the package maintainer made an important package behave stupidly.

@Wolf480pl
(Ex., if the default install would overwrite a meaningfully distinct package that a lot of existing code depends on, then naturally the package info would prevent such overwriting.)

@enkiv2
ok, so some packages install to /bin, some to /usr/bin, some to /usr/local/bin, and some to /package/{package-name}, and there's no distro-wide consistency whatsoever?
That sounds like a mess.
And a pain.

@Wolf480pl
Why would there need to be a distro-wide consistency about default $PATH stuff?

Almost nothing installs to /package/{package-name} with the exception of proprietary sun stuff. Everything that uses autotools will default to /usr/local/bin unless overridden by the package maintainer.

In my experience, arch & debian are less consistent about which bin directory things get installed to. So, you're using 'which' when it matters anyway.

@Wolf480pl
The policy is 'do what you'd do if you were installing from the source tarball', which is implemented by installing from the source tarball.

In other words: "do not assume that the distro maintainer knows more about a third-party package than the package maintainer"

A distro is a collection of unrelated packages by other people. Any consistency is a shallow illusion formed through genuinely dangerous meddling.

@enkiv2
I don't assume the distro-specific package maintainer knows more about a piece of sotware than the upstream knows.
But I do assume that the distro-specific package maitainer knows more about the package than I do.

@enkiv2
A distro is a collection of related packages, organized in a way that they work in harmony with each other, and together work towards a coherent vision of what an operating system should look like.

@Wolf480pl
The distro maintainer is just a mid-tier seasoned user who doesn't mind fixing their own package problems.

I am a mid-tier seasoned user who doesn't mind fixing my own package problems. I've got strong opinions about how my computer should be arranged -- opinions that no distro maintainer agrees with.

I don't feel like imposing those opinions on people who aren't able to understand or compensate for them. That's why I'm not a distro maintainer.

@Wolf480pl
(It's not all that much work, because unlike an arch maintainer, I don't need to care about packages I don't personally use.)

@enkiv2 I don't think in Arch there's anyone maintaining a package they don't personally use. If nobody in the core team uses a package, it does to [community], and if no Trusted User uses a package, it is dropped from the repos, or moved to AUR.

@enkiv2 You are.
You are maintaining your own distro with a single user.

@Wolf480pl
Yup. It's less effort than the alternative, considering my skills & the kinds of packages I use.

I will use a mainstream distro if I need to support the occasional proprietary closed-source BS app, like skype.

@enkiv2 I do not need to maintain my own single-user distro, because I mostly agree with the choices Arch makes.

If you cannot find a distro you can agree with, then I guess maintaining your own single-user distro is the right thing to do.

But that does not mean multi-user distros are objectively worse.
Or that their users are noobs because they can't maintain their own single-user distro.

@enkiv2
In Arch, everything is in /usr/bin.
/bin, /sbin, and /usr/sbin are symlinks to it.

>Almost nothing installs to /package/{package-name}

There's this group of devs, IIRC runit- and djb-related, who insist on putting everything in /package/{package-name}. So I wouldn't be surprised if some qmail fork used it.

Also, IIRC there are many packages who put other (non-$PATH) files at weird places in the filesystem and need to be ./configured to comply with hier(7) and file-hierarchy(7)

@Wolf480pl
When it's a problem, it's an upstream problem. They should get the bug reports and patches.

When it's not a problem, it's not a problem.

Lunar deals with the very occasional super-weird install path by adding to the default shell profile or creating symlinks as part of the install process. More often, they reject the package entirely because too much effort needs to be done to make it usable & the user should just install the package themselves at that point.

@enkiv2 What if upstream explicitely opposes hier(7)? Or at least their defaults go against hier(7) ?

There are many choices where there is no technically superior answer that's good for all tastes and use-cases.
There is a space for disagreement without either side being wrong.
And then the right thing for the upstream is to make it configurable.
And the right thing for a distro is to set that configuration option in a consistent way across all packages.

@Wolf480pl
The user who is capable of making that kind of decision is a user who should be given the opportunity to make it.

If it's a genuine bug, upstream gets the bug report. If upstream doesn't like it, user gets the opportunity to fork or maintain third party patches.

Distro has no dog in such a game.

@enkiv2 If there are 100 users who agree on those decisions, there's no point for each of them to duplicate the work and build those packages on their own.

@Wolf480pl
100 users who don't know about the topic will be happy with whatever isn't overtly offensive.

100 users who know how to do these things will have vociferous disagreements about how to do them, and should be allowed to make those choices themselves.

Reasonable defaults are provided by package maintainers.

Distro maintainers drink beer & insult each other on IRC.

@enkiv2 @Wolf480pl
>we do not patch files at all

what about bugs to fix serious compatibility problems in software?

@Wolf480pl @a_breakin_glass Upstream's problem. Any package that is not compatible with any other package is broken.

@Wolf480pl @a_breakin_glass In practice, this mostly happens in giant-ass broken-ass ecosystems like gnome or kde where the expectation is that only patch-happy distro maintainers will actually build it outside of toy test situations, & so I either avoid them altogether or patch them myself when I see a problem. A maintainer is a proxy savvy-user picking up the slack for noobs, and I'm happy to not have gnome if it means not needing to second-guess one.

@enkiv2 @a_breakin_glass
good luck being compatible with openssl 1.0.x and 1.1.x at the same time.

@Wolf480pl @a_breakin_glass
Why would I need to be? I rebuild any dependent package if I upgrade a minor version & I have separate packages for major versions in the case that both need to be installed simultaneously.

No distro maintainer is going to be more capable of reliably writing significant code changes to a third-party project than the project maintainer. If I care enough about a version bump, I can write those changes myself & submit an upstream patch.

@enkiv2 @a_breakin_glass
the problem is, there are backwards-incompatible API between openssl 1.0.x and 1.1.x.
So a package will _never_ be compatible with both.

@enkiv2 @a_breakin_glass
Well unless you resort to #ifdefs, but you get the idea.

@enkiv2 @a_breakin_glass
I was responding to:

>Any package that is not compatible with any other package is broken.

And my point is that there are pairs of packages (X, Y), such that no package that uses X can be compatible with Y, and vice versa.