[Pkg-squeak-devel] Bug#634240: [Vm-dev] Re: squeak-vm_4.4.7.2357-1.1_i386.changes REJECTED

[Hector Oron]

Hello Ian,

[Add CC to original Debian Bug report and Neil Williams for providing
patch for fixing the problem]

2012/3/4 David T. Lewis <lewis at mail.msen.com>:
> On Sat, Mar 03, 2012 at 04:06:06PM -0800, Ian Piumarta wrote:
>> Hi All,
>>
>> The quoted correspondence didn't quite go far enough back to give me details of the original complaint against the embedded library sources, so I could be peeing against entirely the wrong tree, but with that caveat...
>>
>> On Sat, Mar 03, 2012 at 02:19:04PM +0100, Bert Freudenberg wrote:
>> >>
>> >> The embedding of source code for libraries in the Squeak VM sources is historical, probably to spare builders the hassle of hunting down the right sources. On Linux it doesn't really make sense to do that, agreed.
>>
>> Off the top of my head, by using identical plugin sources on all platforms we can:
>>
>> 1. Guarantee access to the plugins for all POSIX-like platforms, including several that were around long before Linux was invented, by including a version of the library that we know has no particular dependencies on any given platform or architecture;
>>
>> 2. Guarantee access to the plugins on platforms that choose not to bundle the required libraries or for which the library maintainer chooses not to spend any time providing compatibility or maintenance (this and the previous are pretty much the above 'historical' that you mention);
>>
>> 3. Guarantee bit-identical results across all platforms;
>>
>> 4. Guarantee no risk of API divergence between a plugin and whatever version of its encapsulated library a given platform chooses to call canonical this week;
>>
>> 5. Guarantee that bugs fixed for the affected plugins/libraries on non-Linux platforms provide benefit to the Linux VM too;
>>
>> 6. Guarantee that bugs fixed for the affected plugins/libraries on the Linux platforms provide benefit to the VMs for all other platforms too;
>>
>> 7. Guarantee adherence to the principle of not fixing something that isn't broken (insofar as our versions rely only on portable standards and a given platform on which we compile adheres properly to those standards);
>>
>> 8. Guarantee that the plugins continue to function when some OS or variant of it decides to replace a bundled library with a newer, bug-ridden, un[der]-tested, 'equivalent' library that most probably comes with a 'better' but completely incompatible API designed with no consideration for backwards compatibility.
>>
>> All of the above are important (and in some cases critical) to someone, somewhere, and the last one has bitten me several times -- and continues to do so to this day.

In Linux distributions, at least Debian, we care about security, if we
have a security bug against libjpeg, that means all the packages
shipping embedded copies have to be patched, and even worse those
packages can have multiple different and modified embedded copies of
the same source. I think you can imagine, security wise, what the
overhead is. Linux distributions, at least Debian, pick just ship one
copy of the library and link software with it, so when a problem
appears, only one patch is needed and the rest of the distribution
benefits from that. If something breaks, then fixing is a must of
course.

>> That said, it would be easy to arrange the CMake files to link a given plugin against a compatible platform-supplied library thereby permitting the given packaging process (for a Linux distribution that objects to the embedded library sources) to remove those parts of Cross that are unwanted.  That's an issue for the maintainer working for the distribution in question and I'd be happy to work with the first of them that determines such a mechanism to be necessary.  The maintainer in question would of course have to understand that by creating a special case for their distribution they would be assuming primary responsibility for solving subsequent compatibility issues (cases 4 and 8) with no guarantee that anyone in the Squeak community would consider the issues high priority or be inclined to help fix them considering their self-inflicted and essentially arbitrary cause.  Of course it is always possible that the current version of a particular library on a particular platform has already become incompatible with our plugins, which would immediate place the package maintainer for the affected platform in the precarious situation mentioned above.
>>
>> A few '--with' options, as were already suggested by Dave I think, are a good first approximation that permits linking against a platform library rather than an embedded one.  Once they are in place it would be very little work to make them the default on a particular distribution leaving the packager free to excise the embedded library sources.
>>
>> Now, what was the problem?  :)

We fixed several problems, and patch is attached at (thanks Neil Williams):
< http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=33;filename=634240.diff;att=1;bug=634240
>

If you could verify the patch and apply the ARM fixes upstream and
make it easier packaging wise to link with system libraries instead
embedded copies, then that would be superb.

In anycase, thanks, for your detailed description.

> Hi Ian,
>
> Yes, I believe that it is a matter of using platform libraries, and
> requiring that copies of platform libraries not be present in the source
> tarball.
>
> My understanding of the issue is that Linux distributions require
> packages to be built from source (your tarball in this case, or some
> modification thereof), and require that this source follow the rules
> with respect to licensing and so forth. Apparently one of the rules
> is that if a library is provided by the Linux distribution itself,
> then the platform provided library should be used, and a local (and
> probably different) version of that library should not be present
> in the Squeak VM tarball.
>
> I am not an expert in Linux distributions, so I'll look to Bert to
> correct me if I have this wrong. But in a nutshell, I think that's
> the issue.
>
> If we could address the build and link issues with cmake as you describe
> above, and then provide some guidance to Linux distribution maintainers
> as to the correct command line options for unix/cmake/configure, I think
> it would be a big help.
>
> I suspect (but do not know for sure) that it may also be helpful to
> provide a separate tarball specifically for Linux distribution builders,
> in addition to the full tarball that you already produce, with problematic
> libary code removed from platforms/Cross. That may help distribution
> maintainers to package the code without worrying about what files or
> libraries need to be excluded.
>
> Thanks a lot for looking into this. My impression is that we have a
> number of people who are willing to work on Linux distribution packaging,
> but who don't necessarily know the details of how to set up the source
> and build process in a repeatable manner. I'm not sure how many
> different Linux distributions might be ultimately be involved, but
> getting this right on Debian certainly seems like a good place to
> start. After all, if it's good enough for Debian, it's going to be
> good enough for everyone :)
>
> Cheers,
> Dave
>



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.