Hi there,
On 30 August 2017 at 01:39, fao_ <finnoleary_AT_inventati.org> wrote:
> Rather, I am asking your opinions on the general concept and
> how it has been implemented. Specifically, the idea of installing
> under a 'package' directory, and symlinking from there to the
> proper install location. But anything about the general behavior
> of it that you think especially sucky would help, also.
Generally speaking to base a packaging concept on symlinks is a very
bad idea. The GNU stow concept (regardless its actual implementation)
is duct taping symlink hacks.
Symlinks have always been a hack due to Unix' lack of a proper
namespaces approach. Plan 9 later fixed this by introducting a proper
namespaces approach[1] - but even today unices (incl. Linux) have
almost ignored the learnings of Plan 9 with some exceptions.
In a clean environment with a well defined directory structure (that
doesn't allow multiple ways of arranging files) it is a pretty easy
task to locate assets of a certain program. For instance in stali due
to static linkage there are no .so's hanging around in different
paths. Only important directories to look at are /bin and /etc
eventually.
In terms of a packaging manager, I'm a proponent of the idea I
introduced with stali as well. It does not require a package
"manager", but uses git for the rootfs overlay instead. If you want a
certain version of the system, you check out the required version from
/.git.
I'm certain that those ideas would scale up to a general purpose base
system, however if you want to deploy heavyweights like chrome or
openoffice etc. I would try to adopt union mounting overlays into some
/crap namespace of such "packaged" software, rather than using ugly
symlinks with stow.
[1]
http://doc.cat-v.org/plan_9/4th_edition/papers/names
-Anselm
Received on Wed Aug 30 2017 - 06:16:37 CEST