/hg/icedtea: 3 new changesets

[Andrew John Hughes]

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.

>> 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.  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.

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.

>  Matthias
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8