Re: [lfs-support] stow for package management?

[Richard Melville]

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?

[Jorge Almeida]

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?

[Jorge Almeida]

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?

[Michael Shell]

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

[lfs-support] stow for package management?

[Jorge Almeida]

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