[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#14296: libg++272 patches for Alpha

[ I am CCing the discussion on the alpha port of libg++272 to the
debian-alpha mailing list because it touches libc6/libc6.1 issue. ]

On Saturday,  1 Nov, joost witteveen wrote:
> > Package: libg++272
> > Version:
> > 
> > While trying to build libg++272, libg++272-dev, libg++272-dbg for the
> > alpha platform I encountered the following problems:
> > 
> [1,2 removed]
> > 
> > 3. There are hardcoded dependencies on libc6 and libc6-dev.  This is not
> > good as the corresponding packages on alpha are called libc6.1 and
> > libc6.1-dev.  It is probably better to do dpkg-shlibdeps and remove the
> > package's dependency on itself afterwards.  I would actually consider
> > reporting such a dependency a bug in dpkg-shlibdeps, which should treat
> > it as a special case and skip it.
> dpkg-shlibdeps used to report the dependancy on itself, but I'm not
> sure it still does. But that only helps for libc6, and not for libc6-dev.

I think it still does (speaking strictly, dpkg-shlibdeps is correct,
it just hits a unique case when a single package contains two shared
libraries, one of which requires the other one).

You are quite right about libc6-dev.  I did not mention this problem in
my bug report because I did not know what to suggest.  A new tool called
dpkg-devlibdeps, which would invoke gcc -M instead of ldd?  Strange idea.
A script which would add -dev to the output of dpkg-shlibdeps?  Looks
too hackish.

> You will have the above problem with libc6-dev for every package that
> depends on lib*-dev, as dpkg-shlibdeps has no way of seeing dependancies
> on the lib*-dev packages.
> Why is the package on the alpha called "libc6.1-dev"? Is that because
> your libc6 really is glibc-1.99-something? Do you still have packages
> that depend on the old "alpha libc6-dev"? If not, wouldn't it be better
> to let alpha-libc6.1-dev provide libc6-dev? This may break a few old 
> packages, that depend on the old alpha libc6-dev, but it will work OK 
> for all the other ones (that is, every package that depends on libc6-dev
> in current hamm).

Recently we had a discussion on this topic.  Probably "Provides: ..." is
the best way for us to go.  There is no libc6 (nor libc6-dev) package on
alpha.  The package is called libc6.1 just to follow the policy
requirement to reflect the exact soname in the name of the package.
(And the soname is really 6.1 because libc.so.6 was actually glibc-1.9x.)

Or shall we discuss dpkg-devlibdeps on debian-devel?  I'll think about

> > Since it is envisioned that libg++-2.7.2 is being obsoleted by
> > libg++-2.8.0, the patches below are attached mostly for the sake of
> > completeness to document the changes that have been made to libg++272
> > while porting it to alpha.  These patches fix problems 1 and 2.
> Do I get that right, and you don't really want me to forward the
> patch upstream? 

Yes, you got it right.  These problems have been fixed in libg++-2.8.0,
and nobody seems to care much about libg++-2.7.2.  I just wanted to say
that I (personally) did not see any reason to propagate the patch
upstream.  Of course, it is a *personal* opinion; I don't use libg++
much, I don't write in C++, so I may be unaware of the real situation.
In other words, I won't be unhappy if you don't send the patch upstream.


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: