The role of distributions &/or Unix flavors, where does pkg management stands - Psychology, Philosophy, and Licenses
Hello fellow nixers,
This thread is about launching one of those discussion podcast.

The topic this time is: What's The role of distributions &/or Unix flavors, where does package management stands in all that?

We'll try to schedule it for next week, so hop on the scheduler interface and put all the hours you might be available so that we can choose the best common denominator:

If you don't have a key you can PM me anywhere for one.

Relevant threads and articles for your personal research might be found in:
Issue #63 of the newsletter ( ) and this week issue #65
the thread "pkg management, what do you expect, what you wished you had" ( )
"GoboLinux and Package Management"
And, obviously, much more, like all or other type of package management or distro management.
More questions to think about:
What is expected from a distro or Unix-flavor
The "from scratch" approach, advantages?
What's the role of package manager?
What's the role of maintainers?
What is the current issue, containers, mini-language-specific-modules, etc..?

Keep your ideas to yourself before the discussion actually take place in the podcast.
This topic wasn't actually discussed so far and it keeps bugging me as the world of package management and distributions go further apart.
When I get a bit more time I'll come back to it. Meanwhile let's mention for those going to FOSDEM that there's a "Dependency Management" devroom that's going to discuss such topic.
I wish there was one way to manage dependencies for all platforms.
(18-01-2020, 07:34 PM)jkl Wrote: I wish there was one way to manage dependencies for all platforms.

pkgsrc is a step toward that. It is the package manager from netbsd, but can be used on many (posix) platforms, including minix.

Package management is a complex topic as different people have different needs.
The only assumption you can have is that everyone will want the manager to not get in their way. This is why debian has the "apt" frontend for dpkg, or yum/dnf for rpms. This is why most of the time "$TOOL install/remove whatever" will work as expected. They follow the principle of least surprise. Unfortunately, such simplicity in the interface/usage comes at the cost of complexity on the packaging side. The packages are cluttered with metadata, pre/post install scripts and so on and so forth.
This is where the user steps in, as some "power users" will want better control over what they install and have the ability to easily review packages amd their dependencies.

I personally care more about having a simple packaging format, than a good dependency handling, mostly because I prefer software that have the least amount of dependencies. I made my own package manager for this purpose, because it lets me review the softwareI fetch, package jt the way I want and install it where I want, with the privileges I set (most of my tools are installed under my UID, in $HOME/.local).
This obviously comes at the cost of having to fetch updates manually, which (for now) is a bit of a burden. But the simplicity of.packaging overweight this for me.
(19-01-2020, 02:23 PM)z3bra Wrote: I wish there was one way to manage dependencies for all platforms.
For Linux specifically, there's Flatpack, AppImage, and Snap. So far, in my opinion, Snap is taking the lead. It's easy to use and works on almost all distros.
Linux is one platform though.
Snap is easy to use, but a pain to manage. This is also a huge step backward IMO, as you put the packaging in the hands of the developer. This os the same nonsense as letting devs push to production directly.
Most of the packing drama comes from the use of dynamic linking; otherwise converting the packages would be more than enough (or patching pkgsrc to build packages). The "new" "solutions" flatpack, appimage, and snap are basically the return to an inferior static linking (sadly, such a model is encouraged by licenses uncertainties). For me, the natural progression of the current insanity is solutions like Nix and Guix.
Static linking avoids dependency hell. I actually prefer that.
Unfortunately, static linking is definitely not manageable nowadays. I gave it a try a few years back, and had a really bad time getting the compiler to behave as I would (gcc is a bitch here, really).

I do agree though that all the new "packaging methods" are really badly done, as you end up with devs shipping their own library versions along with the packages, and you are then dependent on them to push new snaps/flatpack/titi/kaka/whatever when a new patch is needed.
I guess they finally managed to port DLL hell to Linux. This is our future now.

Members  |  Stats  |  Night Mode