[blfs-dev] A question on tags

Ken Moffat 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
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



More information about the blfs-dev mailing list