Re: Fwd: Re: Why no Opera?
Lionel:
>> (Explicitly CCing Edward in the assumption he's not subscribed to this
>> list.
Thank you - I am, indeed, not subscribed.
It would actually be best if you could address me as
packager@opera.com, so that various of my colleagues see the
discussion, too.
>> ... The message I'm answering to is at
>> http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like
>> to be CCed an followups, although subscribed.)
Thanks for the link - and I largely agree with much that's said in
that - see below.
Roberto:
>> > Static linking is considered bad because it is a security
>> > nightmare. You now have extra copies of library code floating
>> > around. Dynamic linking is what the security team likes since it
>> > means that you only update the code once for the whole system.
...
>> > Additionally, static linking destroys any memory utilization benefit of
>> > library code. (...)
Agreed.
These are roughly the arguments I've used in the past to avoid
pressure to "simplify" our packaging by changing to static linking
(which would save us having to address issues of compatibility with
diverse versions of GNU/Linux). The cost is that we have to keep
ourselves up-to-date with existing systems, which increases the number
of distinct builds we have to make (and package and ship). We have
the opera-static version (which static-links Qt, but dynamic-links
everything else) so that we can support those on very old versions of
GNU/Linux; and I don't like the security (or footprint) angle on that,
but it's the best we can think of to do for folk who don't upgrade
their core systems.
>> > However, in the event that there is an update which makes the
>> > library non-binary compatible, then there is another problem. That
>> > is, apps linking against it must be recompiled. With a non-free
>> > product like opera, there would be [no] ability for some well-meaning
>> > Debian Developer to NMU the package (since there is no source) or
>> > for a binNMU to take place if that could fix the problem.
I'm not sure what a binNMU is. As for the NMU problem, for the
foreseeable future, I have to live with opera being non-free, which
means we have to carry the burden of responding in a timely manner to
such ABI-incompatible changes. Naturally, packager@opera.com would be
grateful for any notification of such problems, when they arise.
>> > One possible solution would be for Opera to produce a "source"
>> > package of unlinked binary object files. This would allow relinking
>> > against new versions of the libraries (at least in most cases)
>> > without the need for access to the source.
>> This is already legally required anyway, assuming you link with LGPL
>> code: section 6 of LGPL 2.1.
LGPL 2.1 Section 6.b allows for us to
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
and we use shared linkage for the most part. Even the opera-static
package only statically links Qt (for which we have a separate license
from TrollTech, independent of its availability under GPL or QPL);
everything else is shared-linked.
So my understanding of the legal angle is that providing unlinked
binaries isn't required - please explain why, if you disagree.
>> ... Putting it in a Debian "source package"
>> would only put it in a most convenient form for your users.
Using shared linkage gets the end-user as much ability to replace
libraries (including the X libraries, under BSDoid licenses) as
supplying the linkable binaries - if the ABI changes, they'd need a
new linkable component from us in any case, and otherwise their
replacement shared library will still work.
If I've missed something crucial, please enlighten me !
Roberto again:
> Right. My point was that distributing it in such a fashion might
> address some of the concerns (though not all, of course) about having
> something like Opera even in non-free.
It would help me if you could enumerate those concerns.
Eddy.
Reply to: