Test version of glibc 2.3.5-10

[Aurelien Jarno]

Petr Salinger a écrit :
> Well, new structure might break something, it might be passed between 
> libs. At least for initial upload to unreleased it will be better to not 
> change these structures.

Well I have looked at the source code of some of the affected package 
(see my previous mail for the list), and it seems it is not the case, 
but I can not exclude a problem as I have not made an exhaustive check 
of the code.

> It might be changed later:
> 
> - just before upload to debian.org

I don't know if we will have to rebuild all packages (we have all the 
.changes files so that's possible to reupload them).

Anyway, I think we should avoid to break the ABI when uploading to 
debian.org, as it will probably break the existing installations. We 
can't guarantee that apt-get dist-upgrade will use all packages from 
ftp.debian.org.

We should instead identify the affected packages and binaryNMU them. It 
may still break the existing installation, but apt-get dist-upgrade will 
correct them, due to greater versions.


> - with glibc bump from 2.3.x to 2.4.x
> - ...

Actually if we use symbol versioning, at anytime, given the fact current 
functions are using GLIBC_2.3, we can use any later version.

> Alternatively, leave struct stat consistent with 2.3.0,
> change only struct stat64 to current kernel structure.
> It would vote for this, because 
> it will be consistent with spirit of xxx/xxx64.

What do you mean exactly? Having really different structure (ie old vs 
new) between xxx and xxx64? I am not sure this is a good idea, as the 
available field are different, and that could break something depending 
on if __USE_FILE_OFFSET64 is used or not.

I have an other alternative. As we have the list of affected package, we 
could also send patch to the upstream to use statvfs instead of statfs, 
but that would take more time.

 > Petr
 >
 > P.S.
 > Rebuild with my patch finished, it looks ok.

I think this solution is the good one even for a long time. After all 
this structure is used in about 50 binaries packages (and something like 
35 source package), so why bother so much on it?

So please commit your changes.

Aurelien

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32 at debian.org         | aurelien at aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net