[blfs-dev] A question on tags
zarniwhoop at ntlworld.com
Tue Feb 21 16:31:02 PST 2012
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
> * "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.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the blfs-dev