packaging consistency

[Gene C.]

On Sunday 08 February 2004 15:13, Gene C. wrote:
> I am not sure if this belongs on the fedora-devel or the fedora-test list
> but since most of the discussion on FC1 x86_64 test1 has been here, this is
> the list I am using.
>
> The version of gcc packaged with test1 (3.3.2-5) has a bug which causes the
> compiler to loop.  This was fixed in 3.3.2-6 and works fine.  When I was
> asked about this in the bugzilla report I had submitted, I noticed that
> development now had 3.3.2-8 rather than 3.3.2-6 and I decided to rebuild
> again (not as bad as rebuilding XFree86 but take a long time anyway).
>
> I looked a bit closer at the build printed output this time and noticed
> that a number of files (libraries) where "Installed (but unpackaged)". 
> Looking closer at the list of these files I realized that the 32 bit
> libraries had been generated as well as the 64 bit versions ... reasonable
> since gcc on the x86_64 is capable of generating both 32 bit and 64 bit
> code.
>
> But not all 32 bit libraries were listed.  Checking some of the packages
> such as libobjc showed the reason why ... it had both the 32 bit and 64 bit
> libraries.
>
> Now my question concerning consistency -- how should gcc (and by
> implication glibc) be packaged for the x86_64?  As I see it, there are two
> alternatives.
>
> 1.  Only the 64 bit versions should be packaged as x86_64 rpms but do this
> for all packages and require that the ix86 packages be installed if 32 bit
> support is needed.
>
> 2. Build and distribute both the 32 bit and 64 bit libraries as x86_64
> rpms. If this is done for gcc, then it should also be done for glibc.
>
> I can see arguments either way.
>
> Any comments?  Should I file a bugzilla report on this?

OK, I am answering my own question ... 

There is no packaging consistency problem.  I need to learn to use "rpm -qil" 
rather than "rpm -ql" on the x86_64 so that I get the files listed with their 
package and not all together so that it gives the wrong impression.

There is still a problem with test1 in that the 32 versions of libgnat and 
libf2c are missing.  This will be bugzilla'ed.
-- 
Gene