Moved to LFS-Dev.
On 12/02/2017 10:31 AM, Bruce Dubbs wrote:
DJ Lucas wrote:
As a few of you know, following the move to meson for glib and a
couple of
upgrade issues for people using Porg and some homegrown PMs, I've been
working on ridding us of the libtool archives in a local copy as they are
largely unnecessary, save for a handful of programs that still use
libtool's lt_dlopen function. I believe at least a couple of you had
already been doing this for some time anyway. I'd like to get a quick
review of the status so far (before commit). I know it's not exactly
rocket science, but it is a fairly significant change that will need some
time to settle out.
The svnstash extension on the diffs below is for a silly script I use to
mimic git stash. If interested it's here, but the output is same as
svn diff:
http://www.linuxfromscratch.org/~dj/libtool-removal/etc_profile_d_svn-aliases.sh
A current diff for LFS is available here:
http://www.linuxfromscratch.org/~dj/libtool-removal/lfs-lafile-removal.svnstash
Any comments, suggestions, additional info, better explanations needed on
the added page in chapter 3?
As to the script... Unfortunately, the latest incarnation has yet to be
fully tested due to changes made after I had cleared all of my existing
systems of libtool archives. Could use some help testing here.
http://www.linuxfromscratch.org/~dj/libtool-removal/remove-lafile.sh
And, a significant portion of BLFS is ready to go in as well, (up to a
full Gnome build) here:
http://www.linuxfromscratch.org/~dj/libtool-removal/blfs-libtool-removal.svnstash
I still need to link to the added LFS page in the &rmlibtool; entity and
add a note about upgrading packages (but it would be broken until LFS
gets
the update).
Comments, concerns, suggestions, flames, etc. are welcome.
For LFS, I do not like the invasiveness of the changes. The book builds
fine the way it is and the la files do not impact anything there. I
have told you privately that I prefer just remove all the .la files
optionally at the end of Chapter 6 in the cleaning up section.
find /usr/lib /usr/libexec -name \*.la -print -delete
Yes, I recall you saying that a couple of times, but I was under the
impression that I had convinced you otherwise (for the reason you
mentioned below). I must have misunderstood. As I've also mentioned (in
IRC), this kind of misses the mark IMO. The method I chose puts it front
and center for every single package and completely negates the need for
a script for people just starting with LFS or doing a new build. It's a
new concept that we are introducing to the readers and I'm not sure of
its value. Being very specific was on two fronts. First is in effort to
negate the need for the script in its entirety. The second is in effort
to meet the documentation goal (packages that do not have corresponding
instructions in BLFS can still be updated using LFS instructions), but
its educational value is probably minimal. The instructions could also
simply be appended to the install sections, we don't need a new
<screen/> block if that's the concern.
I know that the .la file may be reintroduced if a user rebuilds a
package using the Chapter 6 instructions, but that is not the purpose of
LFS.
IMO, this is exactly the purpose of LFS. There is a reason that distros
have been doing this for some time, the same reason we are being forced
to do so now. The specifics, however, are hidden from the user, which is
where LFS shines. I might be guilty of hand holding here, but I
certainly don't see it that way. As mentioned above, my goal was for the
script to be completely unneeded if building from scratch, and shortly
thereafter for others. And, yes, I'm aware that does require more work
for the editors.
I'll concede that a solid script is more inline with how a distro
handles this issue in that this is usually a function of the package
manager (before they are ever installed in system locations, and
automated out of existence unless the packager takes steps to prevent
their removal), and that might well be the best way forward. A script is
clearly far less invasive to the book instructions. My concern is that
it becomes an integral part of BLFS rather than a temporary tool to
assist existing users, if they choose to update packages and the build
tool changes.
There is also a loss of fidelity, but I'm reasonably sure that everyone
will agree on it not being super useful if a script is deemed acceptable
as a permanent utility. I don't necessarily have a problem with this
either, this is no different than what distros do with their respective
PMs, but I need to stress the word *permanent* here as I found it
slightly ironic being that was a term I had used to describe the
original problem with libtool archives! :-)
For BLFS, I prefer a script to periodically remove all .la files when
the user desires. That would include scrubbing any .pc files that
mention the .la files like serf-1.pc and excluding those that are needed
by lt_dlopen based packages.
That part is mostly done, but it needs some tweaks to the backups I think.
As far as backups go, that could be done with a simple cp, if desired,
each time the la files are removed. Restoration would be a manual task,
but I do not see that as a problem.
I now agree. The numbered backup scheme was way overkill. But, I'd like
to take it a step further and copy only if it's not already in the
backup location.
In short, I'm good with either method, as long as it gets taken care of.
My preference is obviously the way I've proposed (with arguments above)
over using the script, but let's see if anyone else has something to add.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
