On Tue, Feb 21, 2012 at 03:58:37PM -0800, Qrux wrote:
>
> I think this, too, and I would call it 'run'. To put correctness first, I
> would advocate this hierarchy:
>
> * "Tested"
>
> Compiles, executes, passes regression (if it doesn't work from here, talk to
> the maintainer of the package, not BLFS).
>
Except, almost nothing will ever get tagged like that. If, by
regression, you mean the package's testsuite then it's still
possible that it is misconfigured in BLFS.
> * "Run"
>
> Compiles, executes (which should cover anything from
> no-idea-if-it-works-as-intended through I'm-pretty-sure-it-works-gud).
>
Looks as if this will be what we mostly use, described as 'works
properly'.
> * "Built"
>
> Compiles (look-ma-no-hands..."Hey--'make' worked, and stuff got installed.
> Everything else is on you, buddy).
>
Yeah, that about sums it up - although several that I've labelled
as built are working adequately for me.

> IDK how the current "tagging" is done, but I think those are really the only
> "guarantees" you can ever hand out, and it's probably better not to hand
> anything out if there's any ambiguity. It's probably a good time to start a
> matrix:
>

Looks a bit like gentoo (who mask their ebuilds on some arches).
> i386-generic x86_64-generic (e.g., arm-generic, x86_64-core2, etc)
I think Andy built LFS on i686 today, but in practice most editors
now are probably using x86_64. For -generic vs -variants we don't
care. And we don't care about arm [ in any case, there are too many
arm variants to describe any as generic ]
> -------+---------------+---------------+---------------+-----
> tested | | | |
> run | | | |
> built | | | |
> -------+---------------+---------------+---------------+-----
>
> The first two columns I think are absolutely necessary. BIND, for instances,
> went without verification on x86_64 before getting the "known to build and
> work properly on LFS-7.0" badge. If there was a matrix, that'd be
> incredible. IDK what kind of XML hacking would be needed for this, but
> something that was machine-parseable (say, to generate such a matrix every
> night) but also *easy to edit by hand* would be great, since Bruce's comment
> seems to imply that maintenance burden is a very real concern.
>

Overall, that adds extra complexity. For what purpose ? At the
moment we have e.g.
<!ENTITY lfs70_checked "<para>This package is known to build and work
properly using an LFS-7.0 platform.</para>">
<!ENTITY lfs70_built "<para>This package is known to build using an LFS
7.0 platform but has not been tested.</para>">

So it's just one line ('&lfs70_built;') in the package's xml.

I'm ok with a less-strict interpretation of 'checked'. Adding
extra variants is overhead we don't need : I did suggest this in the
past, but for 32/64 versions of x86 it doesn't buy us a lot. I
suspect that one package in the book might not built on x86_64
(lesstif), and another (libatomic_ops) is not needed for x86_64 - I
suspect that it might not be needed on i686 if LFS was built for
i686 instead of i486.

Äen
--
das eine Mal als TragÃdie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page