At Thu, 23 Feb 2006 22:43:26 +0100, Aurelien Jarno wrote: > I have just uploaded glibc 2.3.6-2. It is now time to think to the next > upload, glibc 2.3.6-3.
Gook work! > Personally here is the things I would like to see in it: > > - Split of libc6 and libc6-dev into libraries and binaries. This is > required as per policy, but become more important for multiarch support. > But maybe there is a reason for having binaries and libraries in the > same package? It depends on the policy. You could split them. However, I wonder we need to do so. > - More architectures using the multiarch directories for the 64-bit > version of the glibc. This will however depends on other packages > > - A policy for the debian/patches directory. This is currently a bit a > mess (and I contributed to it) in this directory, except for the locale > data which is separated. I think the information we need in the patch > filename is: > - a short part telling what the patch does > - the architecture for which it applies > - the upstream status (debian specific, in upstream BTS, fixed in > CVS). For example xfree86 uses number to define that: 000 (patches from > upstream or merged in upstream), 001-899 (patches that should be merged > in upstream), 900-999 (patches that are specific to debian or were > rejected by upstream). I already tried your idea (numbering them), but finally the attempt was failed. 10_cvs.diff is the example of such remains. > Maybe some more information could be put in the filename. Don't hesitate > to give ideas. Then we could put a README file containing the policy in > this directory. I seconded that the information should be always included in the filename. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]