On 03/02/2008, Neil Williams wrote:
> Just imagine the chaos in Debian if the pkgconfig data of
> libgtk+2.0-0 was changed now. Each reverse dependency would then
> need upstream changes to add extra libs to the build that were
> previously implied. That would be just as disruptive as a full
> SONAME transition in Gtk+ itself - how long is it now since gtk1
> became gtk2? Adding a new pc file is the only realistic method that
> I can see because it supports all builds, not just Debian and the
> migration can be done incrementally.
Well, that pkgconfig modification is “your” plan, and I understand
(quite) well the implications it has, but I don't really see how it is
relevant to (not) using LDFLAGS.
> These kind of things have implications far beyond the current
> package but this is, IMHO, TheRightWay(tm) to fix things, not using
> -Wl,--as-needed.
That might be a means. But given the hell we already have, dealing
with upstreams only shipping a .la file, or not shipping any
{.la,.pc} at all, it's not the kind of modifications I'd like to
see happening know.
Again, I said LDFLAGS is a means of getting (quite safely) rid of
extra dependencies, and that it is *not* a silver bullet. Or call
“TheRightWay©®™” if you like.
> In the meantime, I think it's worth being cautious about
> recommending trimming of dependencies. Maybe applications can be
> trimmed without too many consequences but I wouldn't advise trimming
> the dependencies of a library (or library pkgconfig file) on mentors
> - which is a problem because it is with libraries where the benefits
> of trimming are most evident.
Note that I share your concerns about modifying .pc files, but also
that I didn't suggest such a change, ever; since indeed, it would
require serious testing (at least rebuilds, layer by layer, of all
r-depending packages; but also checking whether functionalities were
lost, etc.).
Besides that, I still don't get the “why we wouldn't advise…” part. If
that leads to problem(s), then that'll be reported, and fixed. But not
even *trying* to improve things looks very wrong to me. We have tools
to detect extra dependencies. We have means of getting rid of (some
of) them, others to ensure we don't introduce breakages (like
undefined references). Why not using them? Just stating “that might
not be safe” looks like FUD to me.
If you want dangerous things, I have real examples: the new symbols
feature from dpkg, which already broke several (previously working)
packages on various architectures, be it armel, kfreebsd-*, etc.
Symbols are *not* safe to be used yet, and that has been announced
since the very beginning, by porters, and that has proven to be right
since (and there are still breakages reported nowadays).
If you want another one: using --as-needed without -z,defs, for the
reasons I already mentioned. But I'm not advertising that, either.
AFAICT, the above-mentioned LDFLAGS didn't break packages until now,
and are used quite often (I'd bet see the gnome-related packages,
since lool has been advocating these options in the thread on -devel,
although I didn't check), at least on a bunch of package I maintain,
or that I'm preparing.
Not to mention that we are on -mentors, and that packages get
double-checked, by the sponsoree (which is supposed to have checked
the runtime quite seriously), and by a sponsor, who could at least
spot the use of --as-needed without -z,defs.
Really, I don't see why we shouldn't encourage people using those
options.
Cheers,
--
Cyril Brulebois
Attachment:
pgpHhQUpywUre.pgp
Description: PGP signature