Konstantinos is right with regards to the package naming, we discussed this with the zlib developers at the time.
It is easily solved with a packaging solution though, Provides: as he said. You will have the same problems with something libjpegturbo if it forces NEON, or libmatrix shipped with the GLES test utilities we've seen in our bug reports (btw that is a prime target for some NEON optimization, Konstantinos can you throw some code in there) or in fact any library that has NEON code which is not properly inserted/overridden at runtime based on NEON hwcaps (the concern here is i.MX515 TO2, Marvell and nVidia chips which have broken NEON or no NEON at all). Shipping a libturboz.deb would not be a huge imposition. Given that Genesi provides system images and installers for Ubuntu we can install it by default (TO2 support for installation is going away with Natty). For Debian main, and other distributions which need to figure on supporting more platforms than ours, and for Ubuntu in the future if they ever get their act together on supporting real consumer products instead of just dev boards (looking at you too, Linaro!) then it will have to be a user installable option, but this might not be any more difficult than supplying a metapackage for the platform (like omap-extra) with some Recommends: line, which can only be resolved using an external repository (partner, or so) which is not enabled by default. As soon as someone enables that repo they will have the option at next update to "upgrade" their system to these new libraries. Unfortunately doing it from a distribution point of view takes away all the easiest potential for performance optimization, but I think the benefit of having it "standardized" is worth it. Speaking of standardization, we have had a LOT of customer complaints about xscreensaver-gl being installed by default on ARM platforms. In what world does the common ARM SoC ship with a full OpenGL implementation bolted on? Users are clicking some random 3D screensaver and complaining there is no acceleration - users do not understand the difference here between GL and GLES. As well as making new packages (libturboz in some other repo), it will have to be automated or automatically educating users to understand why they need this package and why, in fact in some cases, they may not actually need it. -- Matt Sealey <m...@genesi-usa.com> Product Development Analyst, Genesi USA, Inc. On Tue, Mar 29, 2011 at 3:07 AM, Konstantinos Margaritis <mar...@genesi-usa.com> wrote: > On 29 March 2011 10:53, Steve Langasek <steve.langa...@linaro.org> wrote: >> Hi Konstantinos, > >> There must be some misunderstanding here; no license that prohibited >> distribution of binaries built from modified source would be considered a >> Free Software license, and zlib is certainly considered free. :) > > Yes, you're right, the problem is that a modified zlib would have to be > clearly > marked as different -ie the package name would have to be different. This > would be easily solved by means of a Provides: field, but I'm unsure if the > differentiation also should include the libz.so filename. I was probably wrong > in my license interpretation in 2005, but I seem to remember it was something > like that that basically made me stop my work in vectorizing zlib :) > > I'd love to be corrected if it meant having a NEON-optimized zlib in 2011 :) > >> The only relevant requirements in the license (according to >> /usr/share/doc/zlib1g/copyright) are: >> >> 1. The origin of this software must not be misrepresented; you must not >> claim that you wrote the original software. If you use this software >> in a product, an acknowledgment in the product documentation would be >> appreciated but is not required. >> 2. Altered source versions must be plainly marked as such, and must not be >> misrepresented as being the original software. > > Yes, 2 is the problem, I think this was interpreted as having to rename > the package and possibly the .so name. > >> Are you looking at a different zlib license than this one? > > No, it's the same. > > Konstantinos > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
