On Sun, Jan 19, 2003 at 12:52:56PM +0100, Thomas Hood wrote: > Question about interpretation of policy: > How acceptable is it to put a debian/shlibs.local into one's > package so that it will require the woody version of libc6 > rather than the version dictated by the current > /var/lib/dpkg/info/libc6.shlibs ? > Technically it is reasonable to do this because whereas > /var/lib/dpkg/info/libc6.shlibs dictates the most > recent version of libc6 (... it has to do this in order > to deal with the worst case of a program that uses > features added in the most recent version ...), most programs > work correctly with older versions (because they don't > use such new features). If you do this, you're the only one to blame if at some point libc6 changes one of the features that you *do* use, and a version of your package built against the new libc6 is installed on someone's system that's running glibc 2.2. You would also need to handle the fact that the library package name is different on two of our archs (alpha and one other -- ia64?). So it's not policy that prevents people from doing this, just sanity. ;) Given the work involved in the first place to verify that the package *can* be used safely with glibc 2.2.5, and then all the things that can go wrong after you've added such an override to your package, I think most people who are aware of this technique have chosen to either focus their efforts on getting glibc into shape, or on being happy in spite of the glibc delays. :) -- Steve Langasek postmodern programmer
Attachment:
pgpi7xYErVOYX.pgp
Description: PGP signature