/hg/icedtea: 3 new changesets

[Matthias Klose]

On 18.11.2009 10:49, Andrew John Hughes wrote:
> 2009/11/18 Matthias Klose<doko at ubuntu.com>:
>> On 17.11.2009 15:58, Andrew John Hughes wrote:
>>>
>>> 2009/11/17 Matthias Klose<doko at ubuntu.com>:
>>>>
>>>> On 17.11.2009 13:44, andrew at icedtea.classpath.org wrote:
>>>>>
>>>>> changeset 9c090fa1a619 in /hg/icedtea
>>>>> details:
>>>>> http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=9c090fa1a619
>>>>> author: Andrew John Hughes<ahughes at redhat.com>
>>>>> date: Tue Nov 17 19:31:54 2009 +0000
>>>>>
>>>>>         Always checksum zips, even if specified with --with-alt-x.
>>>>
>>>> if I understand the patch correctly, then this is the wrong thing to do.
>>>> distributions need to ship modified tarballs with binary files and files
>>>> with questionalble licenses removed.
>>>>
>>>>   Matthias
>>>>
>>>
>>> Do we still have any?  If so, we should be getting them removed upstream.
>>
>> is upstream willing to remove any prebuilt binaries from the tarballs?
>>
>
> Upstream in this case is the IcedTea forest i.e. me -- so yes :)
>
> More seriously, I thought this had all been dealt with a couple of
> years ago.  What you seem to be saying is that the issue has instead
> been sidelined and you've worked around it by cutting your own
> tarballs with bits cut out and thus presumably untested by the rest of
> us.  That worries me to be honest and I think that's the bigger
> problem to solve.
>
> If you can point me to what these problem areas are, we can work on
> removing them both in our trees and Sun's.

see fsg.sh.

>>> I don't think that's a justifiable reason to allow through potential
>>> bogus zips; this patch avoids issues where the build then fails
>>> because someone used an old zip.
>>
>> I honestly disagree; did you see any cases where this did go wrong?
>
> In most cases, I produce a patch due to an issue and that was the case
> here.  Not checking the existing tarballs was allowing an issue with
> the HotSpot check to go unnoticed.  I've also had builds fail in the
> past because my zips are outdated.  Given how long the IcedTea build
> process is, I prefer to catch such errors sooner rather than later.
>
> My use of the alternate zip options has always been to avoid a 50mb
> download on every build.

there are other ways to ensure this, like using a proxy.

> I don't think it's practical to do repeated
> builds any other way.  Clearly you're instead using them to use a
> different tarball altogether, and that's not something I want to
> support by default as such a tarball is not going to have been
> subjected to the same amount of testing.

yes, and that's the way that *all* distributions do the build, using local 
archives without accessing the web, even the fedora build does modify those:

http://cvs.fedoraproject.org/viewvc/devel/java-1.6.0-openjdk/generate-fedora-zip.sh?view=markup

> We can still support it, if necessary, via an additional option e.g.
> --disable-checksums.
>
>>
>>> Worst case, you can change the checksum to match your modified tarball.
>>
>> If you really have to do this (which I disagree with), please only do this
>> for tarballs which are not renamed, e.g. disable the check for anything
>> which name differs from the "upstream" name.
>>
>
> That sounds too much like a hack; I think an additional option is
> appropriate, if we deem it's needed.  Preferably, we need to fix the
> underlying issue.

the underlying issue are distribution builds, and that distributions do modify / 
use different tarballs from time to time. please don't enforce your development 
centric view on packagers.

If you think that the unversioned tarball downloads lead to confusion, then 
maybe just rename these tarballs to include the revision/version number and 
don't use the unversioned ones.

   Matthias