On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote:
>
> 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.
>
It seems like you have made a sensible choice in offering both. After
all, in a free market one must offer what the customer wants or risk
losing the customer altogether.
> >> > 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
A binNMU is simply a rebuild that is triggered by archive admins. That
is, no source changes are required just a recompile. This is often the
case with library transitions so that all the packages that depend on an
old library can be recompiled to depend on the new library. In the past
this required an actual upload, but nowadays they can just trigger it
without an upload. Any package you see with a +b1, +b2 or something
like that at the end of the Debian version has been binNMU'd.
> 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 thing which would help is if you made use of the Bugs: filed in
debian/control. That is you do something like this:
Bugs: mailto:packager@opera.com
This allows people to send bug reports to you directly using the
reportbug tool, which is the preferred tool for submitting bug reports
against Debian packages. That field above will indicate to reportbug
that the report needs to go to that address instead of the Debian BTS
address.
> >> > 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.
>
I believe he was referring to this paragraph from the Preamble:
For example, if you distribute copies of the library, whether
gratis or for a fee, you must give the recipients all the rights
that we gave you. You must make sure that they, too, receive or
can get the source code. If you link other code with the library,
you must provide complete object files to the recipients, so that
they can relink them with the library after making changes to the
library and recompiling it. And you must show them these terms so
they know their rights.
I think that the intent is that user should be able to make non-binary
compatible changes to the library and still relink the non-free work
against the new library.
> >> ... 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 !
>
Not necessarily. If they go and muck with function signatures it may or
may not be the case.
> 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.
>
For that, you will have to ask the ftp masters and the security team. I
am not in a position to speak to their official stance in terms of what
requirements they might have for software like opera to be in Debian and
the Debian Policy manual does not enumerate them either.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature