/hg/icedtea: 3 new changesets

[Andrew John Hughes]

2009/11/18 Matthias Klose <doko at ubuntu.com>:
> 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.
>

Some of this is outdated.

I've removed the binaries that still exist:
http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/f80cf2e0eb9c

The 'questionable license headers' need further examination.  Do you
have any more information on these? Why are they questionable?

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

That sounds like using a sledgehammer to crack a nut; it's a
convoluted solution for what is a simple problem already remedied by
existing means.

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

I don't have a problem with local archives; as I say that's what I'm using.
This particular need to modify them could have been dealt with ages ago.

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

No, the underlying issue I'm referring to here is that there are
binaries and badly licensed files in the OpenJDK source tree that
should be removed upstream.

I'm not trying to enforce anything.  I'm try to work out the best way
to handle this so that all possibilities can be appropriately dealt
with.  As I said in my last e-mail, we can add an option to disable
the checksumming, which then allows the user to acknowledge that they
want to use a non-standard tarball.  Please don't turn a discussion
into an argument.

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



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