[csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy)

[Maciej (Matchek) Blizinski]

2010/3/22 Philip Brown <phil at bolthole.com>:
> On Mon, Mar 22, 2010 at 11:53 AM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>>
>> Specific tools aside, this is a question for release managers: is it
>> worth the trouble to cherry-pick binaries like this, risking an error?
>>  If so, how do we ensure that errors don't happen?  (think: automated
>> checks)  Otherwise, maybe there's less overall risk in just including
>> the 64-bit binaries, even though they might run slightly slower?
>
>
> short answer:
> I thought Dagobert already announced a few weeks ago, that he was
> going to change GAR to default to ONLY building/adding in libraries
> for 64bit, unless explicitly told to do otherwise?
>
> longer answer:
>
> This isnt a problem without GAR.
> GAR should be fixed so it doesnt introduce problems, rather than
> approaching things from the backward approach of "this is difficult to
> do in GAR, so we should make GAR happy"
> :-/
>
> "This is difficult to do in GAR" should not ever be a rationale for
> packaging a certain way. Policy choices should be based on what the
> user sees.

Are you obsessed with this one tool?  I have specifically asked to set
any specific tools aside for the purposes of this conversation.

I'll rephrase the question:

Suppose you're building 32-bit and 64-bit versions of a piece of
software, which includes executable architecture-dependent scripts,
binaries, and shared libraries.  I understand that the policy would be
to:

- install shared libraries for both architectures
- install executable scripts for both architectures
- install binaries for one architecture

There are two kinds of error you can make: include a file that
shouldn't be included, or fail to include a file that should have
been.  The latter error has more profound effect, since if it happens
in the dev package, and it's a *-config script, it can screw up the
compilation of dependent packages.

How do you go about discriminating between the executables (scripts or
binaries) to be or not to be included in the resulting package?  A
method invulnerable to human-error would be preferred.