Re: Installing package *NOT* in repository
-----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-----
Reply to: