Re: [DNG] Dependency Hell: was leveldb support proposal

[Rainer Weikusat]

Didier Kryn  writes:
> Le 02/03/2016 16:04, Steve Litt a écrit :
>> I'm constructing my wpa_supplicant toolset. So far it's 100% /bin/sh.
>> Installation involves nothing more than copying its directory tree
>> somewhere on your computer, and then, on your executable path, putting
>> a 1 line shellscript that calls the main program in my toolset with
>> argument $@.

[...]

> This installation method is used almost consistently by
> Sabotage-Linux.

It's of no big use except if the files belonging to a particular package
have to be kept physically together because there's no other way to
identify them. I've been using this method for software developed as
part of my work and for infrastructure code needed by it and it indeed
works very nicely provided investing the fairly high amount of human
effort required by maintaining it is no problem.

Because this became impossible some years ago, I've then switched to
building (usually pretty bare-bones) Debian packages and found no reason
to regret that so far as this means I only have to maintain one central
package repository and can deploy these to any number of machines with
existing tools very easily.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Mitt Green]

‎Stephanie Daugherty wrote:‎

>There's a fairly elegant, but seldom used solution
>to this problem,. GNU Stow, which is designed to
>basically be a "package manager" for locally installed
>packages.
‎
What about checkinstall? It can create a .deb package
by checkinstall -D. So, instead of make install, ye use this.

Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Stephanie Daugherty]

There's a fairly elegant, but seldom used solution to this problem,. GNU
Stow, which is designed to basically be a "package manager" for locally
installed packages.

It works by using symlinks, so that a "package" foo might be installed into
/usr/local/stow/foo and have bin/  and lib/ and all the other expected
subdirectories. Stow will then install that "package" into the  /usr/local
hierarchy proper on command by symlinking each file into the proper place,
and as an intended side effect of this design, Stow, or even a simple
she'll script can easily find all the symlinks to remove later, since they
all point to the actual installed files in the package installation
directory.

On Wed, Mar 2, 2016, 12:05 Edward Bartolo  wrote:

> Hi,
>
> On 02/03/2016, Steve Litt  wrote:
> > I'm not recommending this for every app. But I've got to tell you, when
> > you think about installation by package manager, with its pinnings and
> > exclusions and dependencies and conflicts, not to mention sabotage of
> > packaging by the poetterists and their ilk, installation by directory
> > starts to have its own charm, for certain applications.
> >
> > SteveT
>
> However, does copying a directory tree to install a program go against
> conventions where various parts of an installation should be placed?
>
> Edward
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Edward Bartolo]

Hi,

On 02/03/2016, Steve Litt  wrote:
> I'm not recommending this for every app. But I've got to tell you, when
> you think about installation by package manager, with its pinnings and
> exclusions and dependencies and conflicts, not to mention sabotage of
> packaging by the poetterists and their ilk, installation by directory
> starts to have its own charm, for certain applications.
>
> SteveT

However, does copying a directory tree to install a program go against
conventions where various parts of an installation should be placed?

Edward
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Dependency Hell: was leveldb support proposal

[Steve Litt]

On Tue, 1 Mar 2016 15:15:05 +0100
Didier Kryn  wrote:

>  I hesitated to reply because I know my answer is politically 
> incorrect. "dependency hell" is the consequence of dynamic linkage. I 
> understand that dynamic linkage is a necessity for distros, but if
> the concern is about one package, this very one can be linked
> statically. 

I'm constructing my wpa_supplicant toolset. So far it's 100% /bin/sh.
Installation involves nothing more than copying its directory tree
somewhere on your computer, and then, on your executable path, putting
a 1 line shellscript that calls the main program in my toolset with
argument $@.

I can copy it to any machine with those two operations, and remove it
by deleting the directory tree and the 1 line shellscript.

I'd like to take credit for this easy installation idea, but of course I
can't. This was the main way of installing programs on MS-DOS. No DLLs.
No .so's. No registry. Just copy the directory, and bang, you're
installed. And so it is that, today, I can still run WordPerfect 5.0,
or Clarion 2.1, decades after my Windows programs became unrunnable.

Let me show you my top level shellscript:

=
#!/bin/sh
mydir=`realpath $0 | sed -e's+/[^/]*$++'`
export PATH=$mydir:$PATH
export AP_SELECTION=/tmp/ap_selection.txt
fcn=$mydir/rw_$1.sh
shift
if test -f $fcn -a -x $fcn; then
$fcn $@
else
echo FAIL: File $fcn must exist and be executable. >&2
echo Aborting. >&2
exit 61
fi
=

Installation by directory is as simple as realpath $0.

I'm not recommending this for every app. But I've got to tell you, when
you think about installation by package manager, with its pinnings and
exclusions and dependencies and conflicts, not to mention sabotage of
packaging by the poetterists and their ilk, installation by directory
starts to have its own charm, for certain applications.

SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng