Bug#266273: Idea for solving JDK 1.5.0 problem

[Alex Owen]

On Tue, 30 Nov 2004, Jeroen van Wolffelaar wrote:
> On Sun, Nov 14, 2004 at 12:02:43AM +0000, Alex Owen wrote:
> > The problem is that the shell script stub on the self extracting binary
> > does the wrong thing!
> >
> > The only way I can see to solve the problem is to patch that shell script
> > stub and move all the setup it does to either the sun-j2sdk1.5debian
> > package (or the postinst of the generated package).
>
> I've looked extensively at this issue, and these are my preliminary
> conclusions:
>
> - Both the RPM and the regular self-extracting bin have the same shell
>   stub in front that unconditionally tries to update mime, install gnome
>   registry stuff, and write to /etc/.java if the username is root (even
>   in fakeroot).
> - The shell script is too complicated to automatically patch into doing
>   the right thing, this can only be done if the exact shellscript is
>   known in advance.
I see no problem with this! That is the way java-package works. It knows
about certain .bin files and how to process them to make a .deb .

> - Sun will probably release updates/patch releases during Sarge's
>   lifetime, so demanding a certain .bin that was at the time of sarge's
>   release available is not good

Again I see no problem with this. The version released with sarge _would_
require one of a limited set of specific .bin files... But then one could
use the testing/unstable version of java-package to install later jdks on
a sarge system. The very nature of installers for non-free software is
that the installer lags the release of the software slightly. The benifit
is that we collaborate and don't individually reinvent the wheel.

One could argue that java-package be a "volatile" package (see threads on
debian-devel in October 2004)

> - The release managers have stated that trying to fiddle with the
>   filesystem is unacceptable during mpkg-java time.
Of course!

> I see two possible solutions:
> - My means of a sed statement kill the whole shell stub, and just
>   extract the binary. Execute the unpacking of the .pack files
>   ourselves.
I see possible legal problems here (IANAL).

> - Ensure in mpkg-java that one is running as a regular user in fakeroot,
>   so that those changes are known to have no effect.
For the case of /etc/.java/ stuff looking at the shell stub I seem to
remember that if you are not root it creates the /etc/.java/ stuff
somewhere in the JDK installation tree. So this may in effect be
impossible.

> With solution (1), probably the license statement should be displayed
> manually, although the user already once click-through'ed it on sun's
> website. It's not entirely sure (1) is even allowed though, legal-wise.
I agree

> Solution (2) might be easiest -- simply refuse to run being real root. I
> checked with the release team, and they are okay with it.
I see where you are getting at but I think the shell stub will do
different bad things if not root. I think your assumption is that it does
no bad things if it is not root.

> I'd really like to get java-package in Sarge really-soon-now. I hope
> that an agreement on (1) or (2) (or a 3rd alternative) can quickly be
> achieved. I think (2) might be the fastest and fail-safest way to get
> his package fixed. Please always Cc me on replies.

A third option is to use a "checkinstall/installwatch" type method for
creating the non-free deb however this would be a major change
to the way java-package works.

>
> It'd IMHO be only a minor bug if those mime-things and gnome registry
> stuff were not performed at all, by the way. Nice to have, but in no way
> essential.
I see no problem for make-jpkg to put a postinst in the generated deb (or
the debian partner pkg for that matter) that does setup these extra
features.

Anyway i hope these comments are constructive.

Alex Owen