Re: Fwd: Re: Why no Opera?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roberto C. Sánchez wrote: 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. The security team gives no support for contrib and non-free packages[1]. Regards, -Roberto [1] http://www.debian.org/security/faq#contrib -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG//EUYy49rUbZzloRAo26AJoDnUVE4RM1TrxytaaqfVTULuk5/wCeLgzr bcNcW7F/4f4Fqkj0QG5Rg+8= =hobb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Sun, Sep 30, 2007 at 01:55:05PM -0500, [EMAIL PROTECTED] wrote: Roberto C. Sánchez wrote: 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. The security team gives no support for contrib and non-free packages[1]. I know. However, supporting and permitting are two different things. Like it or not, there is an association of Debian being involved to some degree or another in the software in contrib and non-free. Not everyone understands that non-free is not really part of Debian. That said, even if everyone understood that perfectly, I don't think that the security team and/or the FTP masters would be thrilled about permitting software in non-free that is very buggy. That was the point I was trying to make. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Fwd: Re: Why no Opera?
On Sunday 09 September 2007 19:19, David Given wrote: Ben Finney wrote: [...] It would behoove you to at least put significant effort into what everyone here agrees would be the best way to get Opera working well with Debian and other free software operating systems. I'd take issue with that statement. Opera don't owe Debian anything; they're packaging their software as Debian packages for their users, not for us. If anything, they're doing us a favour by using our package format. That's their right. It's their software, they own it, they can do whatever they like with it. *We* get no say in that matter. On the other hand, Opera isn't asked to make their browser free software _for Debian_, but for their users. Debian is not an end, but a means. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpdQoN9Vx9te.pgp Description: PGP signature
Re: Fwd: Re: Why no Opera?
Edward Welbourne [EMAIL PROTECTED] writes: Bernd: if opera would be come open-source, I'd be willing to co-maintain and check packages - it would be worth the work. But I'm not willing to spend my free time on closed source if there's no really good reason to do so. I'm afraid this humble coder isn't about to sway that argument; for the present, Opera remains closed, all I can do is make life easier for users. You are much closer to being able to sway that argument than we: you, after all, are directly associated with the people who can make that decision. It would behoove you to at least put significant effort into what everyone here agrees would be the best way to get Opera working well with Debian and other free software operating systems. It would also be very helpful if you could keep us appraised of any response that you have in this area; otherwise a negative result looks to us exactly the same as no attempt at all. -- \ I would rather be exposed to the inconveniences attending too | `\ much liberty than those attending too small a degree of it. | _o__) -- Thomas Jefferson | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Friday 07 September 2007 11:18:18 Edward Welbourne wrote: Can we still hope that there are requests from the Opera developers that a certain set of LGPL libraries are out there that should be distributed with Debian (which they are currently not or in a wrong version or missing patches) that would help to further reduce the footprint of the non-inspectable closed-source bits of the Opera Debian package? Since we dynamic link everything - except for the Qt in our opera-static package - we simply use the dependency mechanisms in the Debian package system to ensure the presence of the libraries on which we depend, all of which are present in standard debian packages already. So I don't think there's anything that fits your description above. Again, if you believe otherwise, I'd be interested to know. I am not seeking for a violation of some license. It is missed opportunities for optimisation that I am after. You have the source, you seek for them :o) Or are there free tools you are developing with that should be part of Debian? Again, all the tools we use in development are present in Debian already. In fact, in practice, the Unix team would not think of using any tool *not* in Debian, simply because most of us use Debian boxes as our main work-stations ;^) This sounds all very Debian-friendly to me. Please consider to maintain and/or co-maintain some free packages for the distribution and become a DD. It should not distract you much or at all from the work you are doing anyway. The DD application procedure may be perceived to take long when measured with the wall clock, the brain tick time should be negligible for you, so don't shy away, please. Cheers, Steffen signature.asc Description: This is a digitally signed message part.
Re: Fwd: Re: Why no Opera?
Can we still hope that there are requests from the Opera developers that a certain set of LGPL libraries are out there that should be distributed with Debian (which they are currently not or in a wrong version or missing patches) that would help to further reduce the footprint of the non-inspectable closed-source bits of the Opera Debian package? Since we dynamic link everything - except for the Qt in our opera-static package - we simply use the dependency mechanisms in the Debian package system to ensure the presence of the libraries on which we depend, all of which are present in standard debian packages already. So I don't think there's anything that fits your description above. Again, if you believe otherwise, I'd be interested to know. Or are there free tools you are developing with that should be part of Debian? Again, all the tools we use in development are present in Debian already. In fact, in practice, the Unix team would not think of using any tool *not* in Debian, simply because most of us use Debian boxes as our main work-stations ;^) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
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:[EMAIL PROTECTED] ah ! OK, thanks for that ... packaging script revised :-) This allows people to send bug reports to you directly using the reportbug tool, I'd sort of assumed Maintainer was used for that ! Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Fri, Sep 07, 2007 at 10:54:06AM +0200, Edward Welbourne wrote: This allows people to send bug reports to you directly using the reportbug tool, I'd sort of assumed Maintainer was used for that ! It is, but not in a way that is useful to you, only useful for packages in Debian proper (or in the contrib / non-free sections of our mirror network). By default, bug reports are sent to the Debian bug tracking system, who does indeed send a copy of the report to the Maintainer. But only for packages it knows about, that is those in Debian; it takes the Maintainer field of the most recently uploaded version of the package from its own database, not from the package as installed on the machine the bug report was made from. Bug reports against packages not part of Debian are, I believe, returned with a message like I don't know anything about package FOO, can't take a bug for it.. Or maybe they are filed in the general category, I'm not sure. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Friday 07 September 2007 08:10:47 Lionel Elie Mamane wrote: On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote: Lionel Mamane: [...] This was written under the assumption that you statically-linked to LGPL libraries, not only Qt. As you now inform me this is not the case, my statement has no base anymore. Can we still hope that there are requests from the Opera developers that a certain set of LGPL libraries are out there that should be distributed with Debian (which they are currently not or in a wrong version or missing patches) that would help to further reduce the footprint of the non-inspectable closed-source bits of the Opera Debian package? Or are there free tools you are developing with that should be part of Debian? If so, then it would seem approrpiate to learn about these as requests for packaging (RFPs) to the Debian bug tracking system. If Operaners felt like developing Debian packages for those missing pieces themselves, then an Interest to Pack (ITP) report should be submitted. The reportbug tool in Debian knows this all, just say reportbug wnpp. New missing Debian packages for Opera would also seem like a brilliant opportunity for paid (!) Opera developers to also develop into Debian developers (http://nm.debian.org). Cheers, Steffen signature.asc Description: This is a digitally signed message part.
Re: Fwd: Re: Why no Opera?
On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote: Lionel Mamane: Roberto Sánchez: 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. (...) and we use shared linkage for the most part. Even the opera-static package only statically links Qt (...); 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. This was written under the assumption that you statically-linked to LGPL libraries, not only Qt. As you now inform me this is not the case, my statement has no base anymore. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
I am not seeking for a violation of some license. I didn't think you were. It is missed opportunities for optimisation that I am after. That's what I understood you to mean. You have the source, you seek for them :o) I really don't think there's anything that fits the bill. Please consider to maintain and/or co-maintain some free packages for the distribution and become a DD. I have asked my boss whether we can treat the time I'd need for this as my training budget allocation; I'll see how that goes ;-) And thank you for the offer to be sponsor - I'll have a look at the work-needing page to see if I find something that appeals, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
you can at least use linda and lintian (-iI) to check your packages, that should help a lot. Indeed - I've been using lintian, and linda's on my set of things to try during my next binge of package work. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Thu, Sep 06, 2007 at 10:21:14AM +0200, Edward Welbourne wrote: you can at least use linda and lintian (-iI) to check your packages, that should help a lot. Indeed - I've been using lintian, and linda's on my set of things to try during my next binge of package work. How about amd64 packages? thanks, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
(Explicitly CCing Edward in the assumption he's not subscribed to this list. 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.) On Wed, Sep 05, 2007 at 09:38:14AM -0400, Roberto C. Sánchez wrote: On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote: On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote: I'm confused. Pierre appears to be saying static is bad, Bruce closed must be static. There are multiple views on this. The problem runs a little deeper than that. 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. 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 ability for some well-meaning Roberto meant would *not* be ability, I presume. Debian Developer to NMU the package (since there is no source) or for a binNMU to take place if that could fix the problem. (That is in the context of a security problem in a library, naturally.) Additionally, static linking destroys any memory utilization benefit of library code. (...) 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. Putting it in a Debian source package would only put it in a most convenient form for your users. However, I tend to be in agreement with others on this list that the best solution would be a Free software release of Opera. AOL, obviously ;-) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Thu, Sep 06, 2007 at 02:27:25PM +0200, Lionel Elie Mamane wrote: (Explicitly CCing Edward in the assumption he's not subscribed to this list. 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.) On Wed, Sep 05, 2007 at 09:38:14AM -0400, Roberto C. Sánchez wrote: On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote: On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote: I'm confused. Pierre appears to be saying static is bad, Bruce closed must be static. There are multiple views on this. The problem runs a little deeper than that. 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. 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 ability for some well-meaning Roberto meant would *not* be ability, I presume. Quite right. My brain works faster than I can type. Debian Developer to NMU the package (since there is no source) or for a binNMU to take place if that could fix the problem. (That is in the context of a security problem in a library, naturally.) Additionally, static linking destroys any memory utilization benefit of library code. (...) 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. Putting it in a Debian source package would only put it in a most convenient form for your users. 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. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
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 [EMAIL PROTECTED], 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, [EMAIL PROTECTED] 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
Re: Fwd: Re: Why no Opera?
Hi debian-devel, The web of trust gave me Mr Johan Herland as the only member of strong set and I took the freedom to place him on the CC line. Johan forwarded you to me. For reference, dpkg -s, or the package's control file, would have told you: Maintainer: Opera Packaging Team [EMAIL PROTECTED] Opera could offer an apt repository for the .deb We already do :-) Here's the line from my /etc/apt/sources.list: deb http://deb.opera.com/opera/ testing non-free There are two packages available (for each of several configurations): opera is the shared-linkage version, opera-static is the statically-linked version. The former comes in two flavours; .5 for sarge and .6 for etch onwards. Things older than sarge are the reason for the static version. With any luck, Claudio (one of the other parties to [EMAIL PROTECTED]) can add more detail on what's behind that ... On Tuesday 28 August 2007 06:46:47 Bruce Sass wrote: On Mon August 27 2007 05:33:05 pm Romain Beauxis wrote: Le Tuesday 28 August 2007 00:17:40 Bruce Sass, vous avez écrit : On Mon August 27 2007 04:05:24 pm Pierre Habouzit wrote: And it's no way we will accept the statically linked version in Debian. Of course, obviously---for software where there is a choice, but for software which can not be built from source because it is closed or not redistributable once modified (which seems to be the case with Opera), putting a statically linked version into the archive sounds like the correct solution. I'm confused. Pierre appears to be saying static is bad, Bruce closed must be static. We have both static and shared packages, so you can take your pick, but which is the one the official Debian repository wants ? I should also note that the existing Opera packages have not been very lintian-compliant. The new 9.50 release (we recently released an alpha) shall deploy my re-write of the scripts that do packaging: this fixes many of the deficiencies you'll find in packages up to 9.23, but I'd greatly appreciate guidance on how to improve what 9.50 does ! Thanks for mirroring our package, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
Dear Edward, many thanks for joining in. On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote: Opera could offer an apt repository for the .deb We already do :-) Here's the line from my /etc/apt/sources.list: deb http://deb.opera.com/opera/ testing non-free I was pointed to it by others on the list and have indicated it on this wiki page http://wiki.debian.org/UnofficialRepositories There are two packages available (for each of several configurations): opera is the shared-linkage version, opera-static is the statically-linked version. The former comes in two flavours; .5 for sarge and .6 for etch onwards. Things older than sarge are the reason for the static version. With any luck, Claudio (one of the other parties to [EMAIL PROTECTED]) can add more detail on what's behind that ... this sounds all very reasonable to me. On Tuesday 28 August 2007 06:46:47 Bruce Sass wrote: On Mon August 27 2007 05:33:05 pm Romain Beauxis wrote: Le Tuesday 28 August 2007 00:17:40 Bruce Sass, vous avez écrit : On Mon August 27 2007 04:05:24 pm Pierre Habouzit wrote: And it's no way we will accept the statically linked version in Debian. Of course, obviously---for software where there is a choice, but for software which can not be built from source because it is closed or not redistributable once modified (which seems to be the case with Opera), putting a statically linked version into the archive sounds like the correct solution. I'm confused. Pierre appears to be saying static is bad, Bruce closed must be static. We have both static and shared packages, so you can take your pick, but which is the one the official Debian repository wants ? There are multiple views on this. Everyone is confused, the minimal confusion is probably on your side since you can see the source. The Non-Opera-Debianers can only guess about it all and remain confused. For efficiency we want it all dynamic, for safety it is probably static. I should also note that the existing Opera packages have not been very lintian-compliant. The new 9.50 release (we recently released an alpha) shall deploy my re-write of the scripts that do packaging: this fixes many of the deficiencies you'll find in packages up to 9.23, but I'd greatly appreciate guidance on how to improve what 9.50 does ! The ultimate solution of course would be an Open Source release. Though you'd certainly do that if you wanted to and others on this list probably will remind you of this idea anyway. So I will be quiet about it :) For a closed source release it would be lovely if you had a Debian developer amongst your Opera developers who can upload packages to the distribution. This way, he could make sure that all the LGPL libraries that you may be shipping as part of your binary distribution appear as Debian packages themselves. Together with the other DDs he would have ensure that those libraries that are already in the distribution are working with Opera. And finally, he could prepare binary uploads of your package for the non-free section. So, the Debian community would have someone (and sadly only one) who can inspect your source and fix issues that arise. The benefit I see for Opera is a further decreased footprint. For an involvement of the community in the packaging of your latest versions I do not see how this would be possible without any knowledge about how Opera is working internally and about what libraries it uses. But this list is certainly the right one for technical issues, be it for packages aiming at your separate repository or for Debian's main one. Best regards Steffen
Re: Fwd: Re: Why no Opera?
On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote: On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote: I'm confused. Pierre appears to be saying static is bad, Bruce closed must be static. We have both static and shared packages, so you can take your pick, but which is the one the official Debian repository wants ? There are multiple views on this. Everyone is confused, the minimal confusion is probably on your side since you can see the source. The Non-Opera-Debianers can only guess about it all and remain confused. For efficiency we want it all dynamic, for safety it is probably static. The problem runs a little deeper than that. Static linking is considered bad because it is a security nightmare. You now have extra copies of library code floating around. The security team is not particularly happy about this sort of thing. Especially in something non-free to which they do not have source-level access. Additionally, static linking destroys any memory utilization benefit of library code. That is, if I have an app that dynamically links to libfoo and another app also uses the same library, but is static linked, then the second app will cause a copy of the code to be loaded. On low resource machines (which is one of Opera's targets), I would consider that bad. Of course, the advantage is that the release engineers would be assured of the versions of the libraries used from the point of release. Dynamic linking is what the security team likes since it means that you only update the code once for the whole system. 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 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. 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. However, I tend to be in agreement with others on this list that the best solution would be a Free software release of Opera. -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Fwd: Re: Why no Opera?
Hi, So, the Debian community would have someone (and sadly only one) who can inspect your source and fix issues that arise. The benefit I see for Opera is a further decreased footprint. if opera would be come open-source, I'd be willing to co-maintain and check packages - it would be worth the work. But I'm not willing to spend my free time on closed source if there's no really good reason to do so. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
Zitat von Roberto C. Sánchez [EMAIL PROTECTED]: Dynamic linking is what the security team likes since it means that you only update the code once for the whole system. 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. That's what ABIs are for. If a new version of a library breaks an application that uses the not-changed API as intended, it is the library that needs to use a new soname. The package dependencies will indicate the needed libraries. Library packages in Debian should reflect the soname, thus the package name changes when the soname changes. No problem, then. HS
Re: Fwd: Re: Why no Opera?
Steffen: So, the Debian community would have someone (and sadly only one) who can inspect your source and fix issues that arise. The benefit I see for Opera is a further decreased footprint. Bernd: if opera would be come open-source, I'd be willing to co-maintain and check packages - it would be worth the work. But I'm not willing to spend my free time on closed source if there's no really good reason to do so. I'm afraid this humble coder isn't about to sway that argument; for the present, Opera remains closed, all I can do is make life easier for users. I entirely appreciate that I can't expect help improving our closed packages, but any help that *is* volunteered would make one more package be a bit closer to conforming to Debian's standards. We've had some very welcome help from the Ubuntu folks, who are largely responsible for the improvements between 9.23 and 9.50, and I'll be reviewing the remaining issues (two of my nine outstanding packaging bugs are Debian-specific) when I have time. Steffen: For a closed source release it would be lovely if you had a Debian developer amongst your Opera developers who can upload packages to the distribution. That's one of the (too many) things I've got on my todo list - get myself trained as a proper Debian developer. For the moment, I just have some scripts (mostly inherited, I've only had time to clean them up so far) that do the packaging mostly right; the scripts know more about Debian packaging than I do, though. Tollef Fog Heen directed me to http://www.debian.org/doc/manuals/maint-guide/ when he was my Ubuntu contact, so I guess I should familiarize myself with that before asking for a sponsor ! Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Wed, Sep 05, 2007 at 04:43:09PM +0200, Hendrik Sattler wrote: Zitat von Roberto C. Sánchez [EMAIL PROTECTED]: Dynamic linking is what the security team likes since it means that you only update the code once for the whole system. 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. That's what ABIs are for. If a new version of a library breaks an application that uses the not-changed API as intended, it is the library that needs to use a new soname. The package dependencies will indicate the needed libraries. Library packages in Debian should reflect the soname, thus the package name changes when the soname changes. No problem, then. I understand that. The point I was trying to get at is that in such cases Debian tries to minimize the proliferation of many versions of libraries in the archive. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Fwd: Re: Why no Opera?
Hi, That's one of the (too many) things I've got on my todo list - get myself trained as a proper Debian developer. For the moment, I just have some scripts (mostly inherited, I've only had time to clean them up so far) that do the packaging mostly right; the scripts know more about Debian packaging than I do, though. Tollef Fog Heen directed me to http://www.debian.org/doc/manuals/maint-guide/ when he was my Ubuntu contact, so I guess I should familiarize myself with that before asking for a sponsor ! you can at least use linda and lintian (-iI) to check your packages, that should help a lot. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
