-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Aug 15, 2018 at 01:26:48AM -0400, Kenneth Parker wrote: > This brings up a question: If I am Installing something outside of the > Packaging Infrastructure (usually, via a TarBall), I usually install inside > of my Home Directory (for example, using $PATH for ~/bin). If I *MUST* > make it available to other Users, I use the /usr/local/* directories. > > Now the question: Does dpkg have options for doing this? (Or would I need > to, still use the "tarball"? (The reason I bring up dpkg, is that it, at > least gives "lip service" to Dependencies).
I don't think so. And if you look at the contortions needed during the regular build process (there are many "system" paths for different things which need (re-)mapping, like /sbin, /bin, /usr/sbin, /usr/bin, /usr/lib, /usr/share/bin, /usr/share/doc and reams of others (last but not least, /etc(, all reflecting a system policy), I don't think this possible at the package install phase at all. It's (barely) possible at the package build phase, and only if the authors were extremely careful or just used a civilised build system. To give you a conundrum to chew on: somewhere deep in the guts of your (compiled) C program, part of some mythical package "furrfu", the path to its first config file, "/etc/furrfu/main.conf" is hardcoded (it better be, because you don't want to force your poor users to always call furrfu -c /etc/furrfu/main.conf or something. If you relocate the package... where's the config file now? (a) /usr/local/etc? (b) /etc? Each one has its upsides and downsides. Assume we want (a): now dpkg would have to live-patch the /usr/local/bin/furrfu binary, to replace "in situ" the config patch. Or replace /usr/local/bin/furrfu by a wrapper shell script calling real-furrfu -c /usr/local/etc/furrfu.conf. And this is supposed to work (more or less uniformly) across upstreams by a huge community of (sometimes very idiosyncratic) authors, which swear by scaringly diverse build systems, from Autotools through Cmake or some of the Java build systems (ever tried Ant, with all its XML goodness?) to most exotic or artisanal ones. And this across roughly 20K (source) packages. There lies the work Debian packagers are doing, picking up the discrepancies between what the upstream's build system is capable of and the policy which keeps your box together (most of the time, that is). To me, they are heroes. So the answer to your question? Download the source package, wrap your head around the build system, re-build, re-package, and you're good to go :-) Alternatively, and this is a /very/ interesting alternative, go have a look at schroot, where you can set up a special environment. Mostly used to achieve clean builds, you can use it for a package which doesn't quite fit into your system (it needs a slightly different libc, for example, or it would trample on locations already needed by another package). Yet another world to discover :-D (basically, that's what the young-uns are doing with all those flatpaks and things, only that I don't really believe in seeing the whole world through this one tool -- but I'm an old fart, y'know). Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAltz28sACgkQBcgs9XrR2kbcEQCeORQ4p2gKaixQlDHw++gkME4I ju0An2yiBeFejN1THWuy85ubedJrB42n =UtYY -----END PGP SIGNATURE-----
