On 01/03/2011 09:51 PM, Bruce Dubbs wrote:
> William Immendorf wrote:
>> There are some new issues with the XZ-utils instructions:
>>
>> 1. There is a redundant PREFIX=/tools in the Ch5 make install command
>> (it's redundant because --prefix=/tools is arleady passed to the
>> configure command)
>
> You're right. I was going from the bzip2 instructions, but that isn't
> fully autotooled like xz utils are.
>
>> 2. XZ-utils is considered a core compression utility (like Bzip2 and
>> Gzip), yet the programs are not on the root partition.
>
> I really didn't consider it a core compression utility since I've never
> really *needed* it. However, both gzip and bzip2 are in /bin. When I
> look at some other distros, I don't see bzip2 in /bin let alone xz. The
> FHS is really old and doesn't address either.
Ouch. Bad decision on the part of the distros IMO. I'd definitely
consider that an issue not to have tar and/or bzip2 on the root
partition for recovery purposes. tar -> bz2 is fairly common for backups
as far as inexpensive solutions. Most of your tape drives have hardware
compression, but external HDDs are perfect for home users and SMEs. I
mean, you can buy 15 external HDDs (with plenty of room for growth) for
the price of a sufficiently large tape drive now days.
>
> The thing is that there is one symlink that would be broken with your
> suggested changes, lzmore, but it seems inconsistent to have
> lz{cmp,diff,grep,{,e,f}grep,less} in one directory and lzma,unlzma, and
> lzcat in another. The same logic goes for the xz* files.
>
> I note that we do split bzip2 files in the way you suggest.
>
> I'd like to get other opinions on this.
Interesting. I had an immediate need for a multilib system for some
32bit binaries I need to run, and I ventured into Cross LFS this weekend
and made a hybrid. Some really neat tricks in there! I especially like
the simplicity of the multiarch-wrapper. Even a couple of suggestions
for the base LFS (two of which actually do pertain to your inquire above).
Anyway, back on topic, since it is fresh in my head, CLFS puts all xz
utils in /bin but I do not know the rational. It might be interesting to
find the discussion as to why in their archives. I'd suspect that it has
something to do with tar (which is also in /bin as hinted above)
attempting to call the externals, but tar is not _linked_ to the
libraries so xz is technically excluded from the /bin and /usr/bin FHS
requirement.
That said, xz format might prove to be nice for backup/recovery purposes
(again as noted above). Also, again taking from CLFS, texinfo has a
patch available to utilize xz format as is current with gz and bz2. Just
a guess, but since xz is being utilized by GNU, it will probably, at
some point in the future, become a dependency of texinfo requiring an
order change (although I agree with Randy's comment the other day
regarding the usefulness of compressed info pages).
http://cross-lfs.org/view/svn/x86_64/final-system/xz-64bit.html
http://cross-lfs.org/view/svn/x86_64/final-system/texinfo.html
Also of interest (which may already be covered by sed commands currently
in readline) and not at all related to the topic at hand:
readline-6.1-branch_update-1.patch.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
