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/

Attachment: pgpTyLnKOky9G.pgp
Description: PGP signature

Reply via email to