On Thu, 23 Aug 2007 22:26:35 +0100 David Given <[EMAIL PROTECTED]> wrote:
> > Please can you give the details of why this is necessary? > > It's an LD_PRELOAD hack. When glibc calls itself --- for example when fopen() > calls open() --- it does so using a hidden private interface, which means the > preloader library doesn't get a chance to override it. plasticfs wants a glibc > compiled with --disable-hidden-plt to expose this interface. > > Or so the plasticfs docs say --- I'm sure this can be worked around, since > fakeroot and fakechroot manage it, but I wouldn't know how to do that. Also, > I'm working on the assumption that upstream at least know something about what > they're talking about... As Debian maintainer, you need to know a whole lot more about why upstream decided to work this way before adding a duplicate glibc to the archive. 1. Investigate fakeroot and fakechroot. Find out how they work. If you cannot work this out, don't package plasticfs. You are to be the Debian maintainer for this package, you MUST understand enough about how it works to be able to justify both having the package in Debian in the first place and your own packaging decisions. You can't just transfer the blame to the mentors list and say "I have almost no idea how or why *my* package requires a duplicate glibc but this is how I was told to do it on mentors.debian.net". Do the work and come back to the list with a detailed reasoning for what is a MAJOR packaging decision. This isn't "yet another customised version of a package" it is a COPY of GLIBC! Such things are not to be done lightly - especially when you appear to have very little understanding of why this would even be desirable. 2. Find out precisely why your package needs this interface - maybe it is just that upstream are trying to get around problems that don't apply to the Debian package, maybe there were problems building the upstream code on Fedora or OSX or something. Find out if any upstream developers use Debian. 3. Detail *PRECISELY* why your package needs this interface - what it does with it, why it cannot use the standard interface, which calls are made and why (including the filenames, function names and line numbers in the source code). Which parts of the functionality of the package are affected. How other packages deal with the same issue and *detailed* explanations of why your package cannot use those methods. What are the alternatives, which parts of the codebase need patching to use the standard glibc? Do the proposed patches work? Why not? 4. Do not assume that upstream have any idea of what happens inside a distribution. Upstream cares about upstream generally - they care about the .tar.gz, not the .deb or .rpm. Find out if there is a .rpm or maybe a gentoo emerge build. Work out how they do things. This ties into (3) because if you know which distro(s) upstream developers are using, you know where to start looking at how the upstream code is packaged elsewhere. 5. You will need a watertight argument to persuade the glibc maintainers that Debian needs a slightly customised version that will *always* be out of sync and out of step with the Debian package. Generally, such versions are simply BAD IDEAS that have not been thought through. Do *not* approach the glibc maintainers for advice at this stage - find out a whole lot more if you want to be taken seriously. Describing your main reason as a "hack" is not going to win you any friends amongst the glibc maintainers and you DO need to get them on your side. If you cannot provide sufficient, detailed, arguments to put your case, you could find an RC bug appearing against your package before it even leaves NEW. There is zero point searching for a sponsor for a package that is likely to be rejected upon upload so do your homework beforehand and work out if, how and why you need to do things this way. Then double-check all your arguments and finally, throw out all your reasons to copy glibc and find a way to work with the standard glibc. :-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpTyLnKOky9G.pgp
Description: PGP signature