Re: [lfs-support] stow for package management?
On 6 January 2018 at 02:08, Michael Shell wrote: > On Fri, 5 Jan 2018 20:51:58 + > Jorge Almeida wrote: > > > I just found out about stow. It just seems too good to be true. So: > > did I misunderstood something? Any gotchas that are not obvious? > > One package manager I have used before is porg (It had that name > long before Star Wars ever used it. Now we have to search using > > porg package manager > > rather than just porg to find the correct related sites): > > http://porg.sourceforge.net/ > > and I do like it. It does not use simlinks, but rather maintains > a database of the files installed. With stow, this filelist > information is carried by the symlinks themselves. The advantage > of stow is that the package installation step does not have to be > done as root. > > +1 for porg. I've used it continuously since it was paco and it works well for me. Richard -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] stow for package management?
On Sat, Jan 6, 2018 at 2:08 AM, Michael Shell wrote: > On Fri, 5 Jan 2018 20:51:58 + > Jorge Almeida wrote: > >> I just found out about stow. It just seems too good to be true. So: >> did I misunderstood something? Any gotchas that are not obvious? > > > > Another possible "gotcha" is when the package to be installed wants > to tweak something (else) in the main filesystem, say /etc, versus > just add something to /path/to/stow/foo/etc Yes, I suppose that was to be expected. Still, much better than installing and loosing track... > One package manager I have used before is porg (It had that name > long before Star Wars ever used it. Now we have to search using > > and I do like it. It does not use simlinks, but rather maintains > a database of the files installed. With stow, this filelist > information is carried by the symlinks themselves. The advantage > of stow is that the package installation step does not have to be > done as root. > I suppose the database must require at least the same amount of space as the forest of symlinks, probably more, so I think my reluctance about the symlinks was unwarranted. I found about porg yesterday (and I didn't see the SW movie yet!!). The interface seems nice, but the talk about the innards (catching system call et al.) makes me uncomfortable. The down-to-earth approach of stow seems to match the LFS way. Cheers Jorge -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] stow for package management?
On Sat, Jan 6, 2018 at 12:59 AM, Erich Schulman (KT4VOL/KTN4CA) wrote: > On Friday, January 5, 2018, Jorge Almeida wrote: >> >> > >> > I have used xstow on my Debian box since 2010. (Despite the "x", it is not a > GUI application.) I have been pleased with it. My pattern is ./configure > --prefix=/usr/local/stow/foo-1.0.0; make install, and then I xstow the > package. > > You'll want to look at and edit the xstow.ini file. In particular, you'll > likely want to add directories to the list of dirs to never remove -- > perhaps your entire existing /usr/local tree (assuming you use > /usr/local/stow). When you are ready to make install something, check that > every directory needed under /usr/local exists first. Make any new dirs, > make install, then run xstow. Example: if foo(6) creates a man6/foo.6 file, > be sure the /usr/local/share/man/man6 directory exists before you run xstow. > Once I paid attention to those details I have never had a problem with > xstow. > > Xstow indeed makes symbolic links. Every file in and below > /usr/local/stow/foo-1.0.0 will get a symlink in its corresponding place > under /usr/local. They are removed when you uninstall a package. Foo's > directory will be left intact so you can re-stow or delete as desired. > > Give it a try. Find a source tarball that's small and doesn't create a lot > of files. Then install and uninstall the package with your file manager > running and see how it works. > I'll take a look at xstow, to see the differences from plain stow. I already installed two packages with stow and it went well. Thanks for the input. Jorge -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] stow for package management?
On Fri, 5 Jan 2018 20:51:58 + Jorge Almeida wrote: > I just found out about stow. It just seems too good to be true. So: > did I misunderstood something? Any gotchas that are not obvious? Jorge, I haven't used stow myself so I can't comment on how well it works. I think it would work in almost all cases and that the packages with problems would be those that have trouble when installing to *any* directory other than /usr or /usr/local. Another possible "gotcha" is when the package to be installed wants to tweak something (else) in the main filesystem, say /etc, versus just add something to /path/to/stow/foo/etc One package manager I have used before is porg (It had that name long before Star Wars ever used it. Now we have to search using porg package manager rather than just porg to find the correct related sites): http://porg.sourceforge.net/ and I do like it. It does not use simlinks, but rather maintains a database of the files installed. With stow, this filelist information is carried by the symlinks themselves. The advantage of stow is that the package installation step does not have to be done as root. Cheers, Mike Shell -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] stow for package management?
On Friday, January 5, 2018, Jorge Almeida wrote: > > > I just found out about stow. It just seems too good to be true. So: > did I misunderstood something? Any gotchas that are not obvious? > For example, would it be reasonable to install binutils+gcc+glibc the > usual way (in Ch. 6) and then all the rest via stow? > Any corner cases that stow cannot deal with adequately? Would it build > an enormous forest of symlinks? (That is, would it require too much > space? I know disks are huge, but still...) > > In case someone has experience with stow, past or current, I would > like to know your impressions before investing time on stow. > > I have used xstow on my Debian box since 2010. (Despite the "x", it is not a GUI application.) I have been pleased with it. My pattern is ./configure --prefix=/usr/local/stow/foo-1.0.0; make install, and then I xstow the package. You'll want to look at and edit the xstow.ini file. In particular, you'll likely want to add directories to the list of dirs to never remove -- perhaps your entire existing /usr/local tree (assuming you use /usr/local/stow). When you are ready to make install something, check that every directory needed under /usr/local exists first. Make any new dirs, make install, then run xstow. Example: if foo(6) creates a man6/foo.6 file, be sure the /usr/local/share/man/man6 directory exists before you run xstow. Once I paid attention to those details I have never had a problem with xstow. Xstow indeed makes symbolic links. Every file in and below /usr/local/stow/foo-1.0.0 will get a symlink in its corresponding place under /usr/local. They are removed when you uninstall a package. Foo's directory will be left intact so you can re-stow or delete as desired. Give it a try. Find a source tarball that's small and doesn't create a lot of files. Then install and uninstall the package with your file manager running and see how it works. -- 「女のこが天使じゃない 魔物が半分FIFTY」 ジャングルはいつもハレのちグゥ -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[lfs-support] stow for package management?
The LFS book in "Symlink Style Package Management" (6.3.2.3) mentions that make DESTDIR=/usr/pkg/libfoo/1.1 install would work, except that not all packages come with a Makefile supporting DESTDIR. However, with GNU stow we can do something like make install prefix=/path/to/stow/foo and then stow -t /path/to/targetfs foo This wouldn't be dependent on a Makefile being well-behaved (am I wrong with this?) (http://blog.danieroux.com/2005/08/07/using-gnu-stow-to-manage-source-installs) I just found out about stow. It just seems too good to be true. So: did I misunderstood something? Any gotchas that are not obvious? For example, would it be reasonable to install binutils+gcc+glibc the usual way (in Ch. 6) and then all the rest via stow? Any corner cases that stow cannot deal with adequately? Would it build an enormous forest of symlinks? (That is, would it require too much space? I know disks are huge, but still...) In case someone has experience with stow, past or current, I would like to know your impressions before investing time on stow. Thanks Jorge Almeida -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style