package management discussion - Programming On Unix
jkl
The only relevant problem here might be that it affects portability in a negative way. I agree that the historical file system hierarchy in Unix and wannabe-Unix was broken from the moment when binaries were spilling into /usr. Only one of the things where Plan 9 excels: /usr is for users, period.

edit: I shouldn’t type before my third cup of coffee.
z3bra
Agreed that plan9 managed to keep things clear. As I said, this is because of the union mounts. The Linux kernel support these too (see overlayfs, but they're barely used. This could definitely close the issue with our 1km long $PATH, by mergin all binary locations to /bin. There is one issue with it though: permissions. plan9 has a namespace for every user, which means that they can mount directories however they want, it will never affect other users. Under Linux distributions however, all users are part of the same namespace, and thus mounting stuff over / require administrative permissions.

The Linux kernel has a decent namespace support though, including mountpoints. It would be interesting to see what would happen if a new namespace where created for the user in his ~/.profile... ?

EDIT: Got my answer: http://www.halfdog.net/Security/2015/Use...WriteExec/
So it works, but can lead to a privilege escalation bug (though the bug is 5 years old, so I hope it's fixed now :)).
Long story short, user in an unprivileged namespace receive the CAP_SYSADMIN capabilities, and can thus mount whatever shit they need in the namespace. The fact it is unprivileged means that no special permission is needed to create a new namespace. I'll try this out !
ckester
(29-05-2020, 03:58 AM)jkl Wrote: edit: I shouldn’t type before my third cup of coffee.

I had to laugh, because on my system the timestamp of your message is shown as 11:58 PM.

Pulling all-nighters again, jkl?
vain
(26-05-2020, 07:35 PM)z3bra Wrote: Dependency resolution is a complex task with a lot of research to back it up. Doing it simply, however, is complex.

I never tried to write a package manager (because if the distribution doesn't provide a good one, then I tend to not use that distro in the first place), so I might be a bit naïve here: Could you elaborate on what makes dependency resolution complex? Isn't building a dependency tree and then doing topological sort enough? (Possibly by simply resolving dependencies recursively?)

Or did I misunderstand and your point was that it can be hard to do it in a dead simple way? If so, why?
z3bra
(31-05-2020, 02:47 AM)vain Wrote: Isn't building a dependency tree and then doing topological sort enough? (Possibly by simply resolving dependencies recursively?)

Well that's already a bit complex. But the most complex part isn't to "find" the dependencies. It is to keep them up to date and accurate when you maintain your own package infrastructure. Because you need to find a clean way to ensure that you actually listed all required dependency. An eventual solution is to build packs in a chroot where you only install those deps for example.
And then you'll also face the "build VS. runtime" dependency problem…

Really, what's complex with dependency resolution, is to get them right in the first place.

Oh. and there is the cyclic dependencies handling problem too. How do you deal with this:

gcc: require libc, libstdc++, make, gcc
libc: require gcc

It is mostly an issue at build time (though you can find cyclic deps at runtime too…), but you'll encounter this fairly often, especially for the components of your toolchain.
sth
(31-05-2020, 04:14 AM)z3bra Wrote: gcc: require libc, libstdc++, make, gcc
libc: require gcc

this is exactly why i plan on decoupling the dependency resolution from the package installation - check manifests and generate a list of all unique dependencies recursively that are not already installed, then install each package in that list.
it wont avoid every issue but i'm hoping that approach will deal with most common problems.
jkl
(29-05-2020, 05:24 PM)ckester Wrote: I had to laugh, because on my system the timestamp of your message is shown as 11:58 PM.

Pulling all-nighters again, jkl?

It’s CEST here. :-)
vain
(31-05-2020, 04:14 AM)z3bra Wrote: But the most complex part isn't to "find" the dependencies. It is to keep them up to date and accurate when you maintain your own package infrastructure.

Ahh, understood. And agreed. One of the many reasons why I don’t want to do this myself. :) I’m very grateful that other people keep track of all that and make their work available to the world for free.
eadwardus
I wrote a package manager: https://github.com/eltanin-os/venus
Complemented by a ports-like {source-based package manager/build system}: https://github.com/eltanin-os/ports

It fetches, does a integrity check, and unpack the files into the $root directory. It's actually a little more complex than one would expect a "simple package manager" to be, it has its own archiver and manifest/config file format.
The "database" is a directory $root/var/pkg with the data files
$root/var/pkg/remote: packages that can be fetched
$root/var/pkg/*: arbitrary sources (such as a cd, another hd, etc.)
$root/var/pkg/local: installed packages
A "database entry" looks like this:
Code:
name:foo
version:1.0
license:MIT
description:dummy package
rdeps{
        # runtime dependencies
        coreutils#*
}
mdeps{
        # construction dependencies
        libc#1.0
}
files{
        # path fletcher32-hash
        bin/file01 86166cc0
}
It's painful to deal with cases where you want to statically link a package, but some of its dependencies can only be linked dynamically, so you need to differ construction/static deps from runtime/dynamic ones.

It has a configuration file under /etc/venus.conf or $HOME/.config/venus.conf
See an example below using /usr/local as $root:
Code:
arch:x86_64
fetch:curl -LO
root:/usr/local
safeurl:https://myrepo.com
uncompress:lzip -dc
url:https://mymirror.com
There are two repository entries to avoid needing to trust a mirror, as the integrity values (crypto hash) and entries would be downloaded from the official repository.

It has no automatic dependency resolution to this moment, although i am considering to add a simple recursive one (similar to the one used by the ports).

About the discussion on separating the packages under /whatever/package_name, like nix/guix/janus/gobo does: It seems a good way to organize things at first, but then you fall to the problem that the entire OS expect a different organization; most of the advantages of separating the packages are lost when you try to solve this (maybe union being an exception, but then you have its own problems)




Members  |  Stats  |  Night Mode