[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

packaging consistency



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?
-- 
Gene




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]