Re: [DNG] Dependency Hell: was leveldb support proposal
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
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 $@. 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. This installation method is used almost consistently by Sabotage-Linux. The final step of package installation is to place symlinks in canonical places. Unfortunately they make an exception for the toolchain, gcc and system libraries. gcc isn't sysrooted and header files and libraries are put in canonical places. I'd like to test your wpa_supplicant toolset. Didier ___ 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 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
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
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
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