Hi there, On 30 August 2017 at 01:39, fao_ <finnole...@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
