[lfs-dev] Are we ready for LFS-7.5?

Armin K. krejzi at email.com
Sun Mar 2 05:29:50 PST 2014

On 03/02/2014 01:38 PM, akhiezer wrote:
>> Date: Sun, 02 Mar 2014 03:06:12 +0100
>> From: "Armin K." <krejzi at email.com>
>> To: LFS Developers Mailinglist <lfs-dev at linuxfromscratch.org>
>> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
> 	.
> 	.
>>>>>> I've just started sendmail.  Actually I'm most interested in getting the
>>>>>> slackware issue settled for LFS.  That's our only holdup for release.
>>>>>>      -- Bruce
>>>>> Why should we care when it's a distribution issue? Every "sane" distro
>>> It's not a 'distribution issue': you're wrong.
>> It is. Package ships *.la file that depends on another *.la file which 
>> no package ships that the former one depends on. Packaging error.
> Nope, you're still misapprehending, to say the least, the picture here:
> and perhaps being misled by a 'quick to condemn & cast out' approach rather
> than a 'learn and understand' attitude; the world - and as we all know,
> certain regions even more than others - doesn't need yet more of the former,
> and could do with much more of the latter.
> The 'a/aaa_elflibs...' package, like the 'a/aaa_base...' and
> 'a/aaa_terminfo...' packages are there to, inter alia, provide foundation to
> the subsequent parts of the install: it's not intended - and the docs make
> that quite clear - that you stop there and have an even minimal consistent
> functioning system. The 'l/...' series &c fill in the rest of the install,
> even for a minimal install.
> Any distro has a sequence of steps that must be completed before they
> are at the stage of a minimum, or full, &c, install. You don't just stop
> partway through the LFS sequence, end up with a system that has 'gaps'
> (e.g not booting), and yell that it's not a 'sane' distro, and why should
> anyone care about it, and the 'packaging' (1 page ~= 1 pkg) is garbage
> cos it didn't auto-prevent that issue, and so on.
> That 'a/aaa_elflibs...' package that you're "going on" about, is
> installed at approx the same stage as the 'a/aaa_base...' package: that
> 'a/aaa_base...' package is equivalent to __section **2.1**__ of the lfs book
> ('chapter02/creatingpartition.html'). You try stopping an lfs build that
> early, and immediately label lfs as not 'sane', and not worth 'caring'
> about, and its packaging system borken, and you just make yourself look
> silly.

I don't really know what are you talking about since I have always had a
problem understading your "style of writing".

But again:

No matter what you say, if a package A installs a file X.Y that requires
file Z.Y and package A doesn't either:

a) pull automatically the package (depend on) that contains file Z.Y
b) ships that file itself

the packaging is broken. Fill a bug against the package that ships
libmpfr.la in your $distribution. Again, it's irrelevant if mpfr uses
host mpfr or not since the target library is static library and it won't
pull host dependencies at all.

In case of LFS, mpfr and mpc are built after GMP, thus *.so and *.la
files for GMP are always there (we don't advise users to rm anything). I
don't know what is being done in slackware, but I still stand that it's
a packaging issue.

You couldn't install a package that contains libmpfr.so and libmpfr.la
(the -dev package) on Debian without it pulling package that contains
libgmp.so and libgmp.la.

As for default slackware install, I am sure it works since they make
sure that everything gets pulled in, including the package that ships
libgmp.{so,la} and libmpfr.{so,la}, but that's not the case with minimal
setup. Missed dependency or such. Been there, done that.

And as a note - try not to take offense. I'd appreciate if you don't
turn every response that describes things differently than you into a
personal insults or such (even minor ones).

Thanks and have fun. Hope you guys figure this out, I tried to give a
few pointers on what's being done wrong on either side, but I am always
wrong and make myself look silly even though everything that I've said
makes (at least some) sense.

Note: My last name is not Krejzi.

More information about the lfs-dev mailing list