[opgelost] Hulp gevraagd voor het maken van een installatiescript

[Pjotr]

Wie kan er een installatiescript maken op basis van de Java-handleiding die ik hier heb gepubliceerd:
http://sites.google.com/site/computertip/java

Het scriptje moet o.a. het bin-bestand van de webstek van Oracle binnentrekken, de map /opt/java/32 (of /opt/java/64) aanmaken, het bin-bestand daarin plaatsen en zich daarin laten uitpakken, de nodige symlinks maken en de plugin plaatsen in .mozilla/plugins.

Ik kan zelf geen script maken, vandaar dat ik hulp vraag van programmeurs.... Dit script is overigens van belang voor zowel Ubuntu als Debian en Linux Mint. De hoofdontwikkelaar van Mint, Clément Lefebvre, heeft zelfs specifiek gevraagd om zo'n script: https://bugs.launchpad.net/linuxmint/+bug/890278/comments/14

Bij voorbaat mijn dank....  

[grizzler]

Als ik dat had geweten... Ik draai al een tijdje een private repository voor een paar familieleden die wat meer ondersteuning nodig hebben dan gebruikelijk. Daarin zitten sinds kort ook java-pakketten versie 6u29, maar dan in dezelfde variant als de vroegere van Debian/Ubuntu, de drie pakketten sun-java6-bin, sun-java6-jre en sun-java6-plugin. Ik was aanvankelijk ook de /opt-kant opgegaan, maar heb uiteindelijk toch voor de oude opzet gekozen. Dat sloot beter aan bij de 6u26 die ze al op hun systemen hadden staan.

Uit het commentaar van Clem begrijp ik dat hij van mening is dat op die manier ingepakt aanbieden geen optie meer is (dacht ik eigenlijk ook, maar wat ik in mijn private repo stop is mijn zaak...). Jammer. Mijn build-scripts zouden met minimale aanpassingen bruikbaar zijn geweest.
Het beoogde installatiescript zou echter een stuk eenvoudiger moeten zijn, alleen al omdat het het opgehaalde bestand niet over drie pakketten hoeft te verdelen en geen deb-pakketten hoeft aan te maken, dus ik wil me daar wel aan wagen.

Tijdsbestek is wat lastiger. Ik heb nogal wat spoedklussen op mijn tafel. Als iemand iets dergelijks al zowat klaar heeft (je weet het niet...) moet die zich vooral niet laten tegenhouden door mijn toezegging.

[Pjotr]

@grizzler: dat zou fantastisch zijn.... Enorm bedankt voor je bereidwilligheid! 

[MauRice2]

Pjotr,

Eigenlijk staat min of meer een installatie script op je site.
Je hoe enkel alle oprdachten op en regel zetten, zonder de sudo, in een install-script-bestand
En het install-scipt-bestand wel met sudo uitvoeren.

Je moet alleen zien uit te zoeken je juiste URL om te downloaden....
Dan zullen het script er ongeveer zo gaan uitzien:

Code: [Selecteer]

#!/bin/bash
# Java download en installatie script.
# Uit te voeren als root!

#### Check for root ####
if [ "$UID" != "0" ]; then
    echo "Uitvoer: sudo ......"
    exit
fi

mkdir /opt/java/...
cd /opt/java/...
wget -c <url-java-versie.bin>
sh java-versie.bin
.....
ln -s /opt/java/..../jre1.6.0_29/lib/amd64/libnpjp2.so /usr/lib/mozilla/plugins/
.....
rm java-versie.bin

Je ziet ook dat ik de Symlink van de plugin in /usr/lib/mozilla/plugins/
Op deze manier heeft iedere gebruiker de plugin tot zijn beschikking.

[erik1984]

Kleine toevoeging aan het script van MauRice2: Kijken of het downloaden is gelukt alvorens de installatie te beginnen.
edit: installatiebestand uitvoerbaar maken als het in /opt/java/ staat

Code: [Selecteer]

#!/bin/bash
# Java download en installatie script.
# Uit te voeren als root!

#### Check for root ####
if [ "$UID" != "0" ]; then
    echo "Uitvoer: sudo ......"
    exit
fi

mkdir /opt/java/...
cd /opt/java/...
wget -c <url-java-versie.bin>
#### See if download succeeded ####
if [ $? -ne 0 ]; then
    echo "Kon het Java-installatiebestand niet downloaden. Controleer of het adres klopt."
    exit
fi
chmod +x java-versie.bin #make executable
sh java-versie.bin
.....
ln -s /opt/java/..../jre1.6.0_29/lib/amd64/libnpjp2.so /usr/lib/mozilla/plugins/
.....
rm java-versie.bin

[dellkubuntu]

Goed werk!Zelf heb ik er geen verstand van.

[grizzler]

Niet voor het een of ander, maar deze insteek lijkt mij wat te kort door de bocht. Uit de launchpaddiscussie krijg ik de indruk dat dit script uiteindelijk deel moet gaan uitmaken van een installeerbaar pakket, bedoeld om de feitelijke installatie van de java runtime uit te voeren. Daar komt wel iets meer bij kijken...

[Johan van Dijk]

Clem bagatelliseert de lekken in Java, onterecht vind ik.
Misbruik van de recent gevonden lekken: http://www.security.nl/artikel/39332/1/Aanvallers_storten_zich_op_vers_Java-lek.html

Gelukkig zijn ze bij Ubuntu bezig om toestemming van Oracle te krijgen om de updates te verspreiden:
https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/881746
(Zie antwoord #18)

[grizzler]

Het is te hopen dat dat wat oplevert, want de constructie met het script wordt geen optimale oplossing...  

Even een terugkoppeling. Gisteren heb ik een en ander even op een rijtje gezet en een begin gemaakt met het script zelf. Met de launchpaddiscussie in gedachten lijkt het me het best een compleet deb-pakket te maken. Het hoofdscript zorgt dan voor alles wat het ophalen en installeren van Oracle's bestand aangaat en aangestuurd door het controlbestand van het pakket kan de pakketbeheerder het opruimen van de verouderde sun-java6-...-pakketten voor zijn rekening nemen. Dat was het idee.

Vanochtend heb ik even gecontroleerd wat de pakketbeheerder doet als ik het verwijderen van sun-java6-bin voorstel en daar ben ik niet echt vrolijk van geworden. Het kan zijn dat het uitdraait op het laten staan van de sun-java6-zooi en alleen het gebruik ervan voorkomen (wat -als ik me goed herinner- aanvankelijk ook de opzet op http://sites.google.com/site/computertip/java was). Ik zoek nog verder uit wat daar mogelijk is.

Het lijkt me overigens wel verstandig om niet alleen 'java' als alternative te linken, maar álle Javatools en manpages die in de runtimeverzameling zitten, net zoals de sun-java6-pakketten doen. Anders zit je voor je het weet toch met een verouderd onderdeel te werken en ík weet niet of dáár geen kwetsbaarheden in zitten.
Verder lijkt het me beter om de pluginlink niet in ~/.mozilla/plugins te zetten, maar in dezelfde mappen onder /usr/lib die sun-java6-plugin gebruikt. Dan voorkom je dat een andere compatibele browser ongemerkt een oude link oppikt.
Ik ga het script in ieder geval in die richting verder uitwerken.

Als het klaar is, moet het uiteraard worden getest. Alphatesten van de 32-bitversie kan ik zelf doen, maar voor de 64-bitversie heb ik de medewerking van iemand anders nodig.

[Pjotr]

@grizzler: klinkt zeer goed! 

Wellicht één opmerking: de koppeling naar ~/.mozilla/plugins. Is die misschien niet toch noodzakelijk, omdat andere webbladeraars zoals Chrome, ook daar plugins zoeken?

[grizzler]

Lijkt me -zeker wat Chrome betreft- niet waarschijnlijk, maar dat zoek ik in ieder geval uit.

[Pjotr]

Lijkt me -zeker wat Chrome betreft- niet waarschijnlijk, maar dat zoek ik in ieder geval uit.

Het klinkt inderdaad onwaarschijnlijk, maar het lijkt toch zo te zijn... Een wat vreemde bron, want het gaat over Windows, maar het principe is in Linux hetzelfde (is althans mijn ervaring):
http://plugindoc.mozdev.org/windows-all.html

Kerncitaat, direct onder de titel:

Opera, Safari and Google Chrome can detect plugins installed for Mozilla Firefox. (...)

Maar goed, misschien kan het ook op jouw manier.... Jouw manier lijkt me ook wat "netter", eigenlijk.

[grizzler]

Het klinkt inderdaad onwaarschijnlijk, maar het lijkt toch zo te zijn... Een wat vreemde bron, want het gaat over Windows, maar het principe is in Linux hetzelfde (is althans mijn ervaring):http://plugindoc.mozdev.org/windows-all.html

Typisch. Maar in dat geval verwacht ik dat ze in /usr/lib/firefox/plugins en/of /usr/lib/mozilla/plugins geïnstalleerde plugins ook zullen zien.

Maar goed, misschien kan het ook op jouw manier.... Jouw manier lijkt me ook wat "netter", eigenlijk.

Het is de manier van het sun-java6-plugin-pakket dat al die tijd door Debian en Ubuntu is geleverd, dus het zou me verbazen als het niet werkte.

Hoe dan ook, ik probeer het te zijner tijd uit met Opera en Chrome en dan merk ik het vanzelf.

[grizzler]

Vanavond nog even tijd gehad om eraan te werken. Het is allerminst klaar maar het komt intussen wel aardig op gang.
=======================
LET OP! NIET GAAN UITPROBEREN!
=======================
Er hoort nog van alles omheen en de belangrijkste elementen zijn sowieso uitgeschakeld. Dit is alleen bedoeld om een indruk te geven van de aanpak.
Het script zou zelfstandig gebruikt kunnen worden, maar als onderdeel van een deb-pakket komt het beter tot zijn recht. De package manager kan dan allerlei zaken voor zijn rekening nemen die anders handmatig of met een boel extra code in het script moeten worden ingesteld.

Code: [Selecteer]

#!/bin/sh -e

# Copyright (C) 2011  <weggehaald ivm e-mailadres>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

ScriptName=update-jre
ScriptVersion=0.3.0
ScriptDate=01-Dec-2011

LogFile=/var/log/$ScriptName.log
Cache=/var/cache/$ScriptName
Data=/usr/share/$ScriptName
JavaDir=/opt/java
TempDir=/tmp/$ScriptName-transfer
Info=$TempDir/infopage
InfoURL=http://www.java.com/en/download/linux_manual.jsp
BinFmtPackage=java-runtime
PluginLeaf=libnpjp2.so
JavaTools='ControlPanel java java_vm javaws jcontrol keytool pack200 policytool rmid rmiregistry unpack200 orbd servertool tnameserv'
BrowserDirs='firefox iceape iceweasel mozilla midbrowser xulrunner xulrunner-addons'
Priority=63 ###### dit is default - nog nagaan wat optimaal is ######

Action=0
Fast=0
Log=0
Verbose=0

# The default texts in case the localized ones are not available
Error=Error
Syntax="Syntax: $ScriptName [-f] [-l] [-v] install|uninstall [-p=dpkg argument]\n
The option switches cannot be combined on the command line (i.e. -fv will not
work; use -f -v).
With the -f switch the timeouts on wget actions are shortened. Logging (to
$LogFile) can be turned on with the -l (lowercase L) switch
and the -v switch causes verbose output.
The main functions install and uninstall should be self explanatory.
The (optional) dpkg argument must always be given last. It should only be used
in a package manager install environment (i.e. {pre|post}{inst|rm} scripts)."
MustBeRoot='must be root'
UnsupArch='unsupported architecture'
BadArgument='unknown option or argument'
Starting="Starting $ScriptName %s\n"
Stopping="Stopping $ScriptName %s\n"
Selected1="Selected action: install\nArchitecture: %s bit\n"
Creating="Creating %s if necessary\n"
DLOptions="Options for wget: %s\n"
DLInfo="Downloading info page $InfoURL . . .\n"
InfoFound="Info page $Info found\n"
InfoFailed='failed to download info page'
NoVersion='unable to determine version number'
Extracted="Extracted version number: %s\n"
NoInstall='unable to determine install directory'
NewInstall="New install directory: %s\n"
CheckingCache="Checking cache . . .\n"
BundleCheck="BundleIds: %s (from info page) =?= %s (from cache)\n"
FromCache="Retrieving binary package %s from cache\n"
WrongPackage="Wrong checksum for cached package %s\n"
DLBinary="Nothing suitable in cache\nDownloading binary package from %s (using --trust-server-names)\n"
BinaryFailed='failed to download binary package'
CleaningUp="Cleaning up name of package to %s\n"
Unpacking="Unpacking binary package . . .\n"
UnpackFailed='unpacking binary package failed'
WrongName='package unpacked with unexpected directory name'
FullPathName="Full path name of plugin: %s\n"
NoPlugin='unable to locate plugin'
SetAlts="Installing alternatives . . .\n"
DoItem="\055 %s\n"
SetBinFormat="Registering binary format for jar (ignoring errors)\n"
ClassDS="Activating class data sharing (ignoring errors)\n"
SetPlugin="Installing plugin . . .\n"
RemoveOld="Removing previous installation %s\n"
ToCache="Caching downloaded package as %s\n"
Selected2="Selected action: uninstall\n"

# Try to load localized texts
if [ -f $Data/locale/${LANG%.*}.texts ]; then
. $Data/locale/${LANG%.*}
elif [ -f $Data/locale/${LANG%_*}.texts ]; then
. $Data/locale/${LANG%_*}
fi

FatalError(){
echo "$Error: $1"
[ $Log = 0 ] || echo "$Error: $1" >>$LogFile
exit 1;
}

Report(){
[ $Verbose = 0 ] || printf "$@"
[ $Log = 0 ] || printf "$@" >>$LogFile
}

ReportCat(){
cat >&2 $1
[ $Log = 0 ] || cat $1 >>$LogFile
}

# Use id instead of UID because sh is dash on Debian/Ubuntu and not bash
[ $(id -u) -ne 0 ] && FatalError "$MustBeRoot"

# Various possibilities: i386, i686, amd64, x86_64
UName_m=$(uname -m)
if [ "$UName_m" = "i386" ] || [ "$UName_m" = "i686" ]; then
Bit=32
Architecture=i386
elif [ "$UName_m" = "amd64" ] || [ "$UName_m" = "x86_64" ]; then
Bit=64
Architecture=amd64
else
FatalError "$UnsupArch"
fi

# Read the command line arguments
while [ "$1" != "" ]; do
case "$1" in
-f) Fast=1; shift;;
-l) Log=1; shift;;
-v) Verbose=1; shift;;
install) Action=1; shift;;
uninstall) Action=2; shift;;
*) if [ "${1%%=*}" = "-p" ]; then Phase=${1#-p=}; break; else FatalError "$BadArgument"; fi
esac
done

[ $Action = 0 ] && { echo "$Syntax"; exit 1; }

Report "$Starting" "$(date --rfc-3339=s)"

case $Action in
1) # install - can only be called from postinst configure
Report "$Selected1" $Bit

Report "$Creating" $JavaDir/$Bit
mkdir -p $JavaDir/$Bit

Report "$Creating" $TempDir
mkdir -p $TempDir

# wget's default is verbose, so use -q (quiet) if not verbose
[ $Verbose = 0 ] && WGetOptions='-q -nd' || WGetOptions="-nd -v --progress=dot:binary"

# fast means less retries and short timeouts (default is 20 and indefinite)
[ $Fast = 0 ] || WGetOptions="$WGetOptions -t 3 -T 15"

Report "$DLOptions" "$WGetOptions"

# Al dan niet ophalen infopagina nog aanpassen i.v.m. mogelijk permanent #######
# draaiende pc's (want dan wordt /tmp niet gewist)...

# retrieve the info page if necessary
if [ -f $Info ]; then
Report "$InfoFound"
else
Report "$DLInfo"
wget $WGetOptions -O $Info $InfoURL || FatalError "$InfoFailed"
fi

Version=$(sed -n '/Recommended/ s/.*Version \(.*\) Update \(.*\) <\/b>$/\1u\2/p' <$Info)
[ -z $Version ] && FatalError "$NoVersion"
Report "$Extracted" $Version

ExtendedVersion=$(echo $Version | sed -n 's/^\(.*\)u\(.*\)$/1.\1.0_\2/p')
[ -z $ExtendedVersion ] && FatalError "$NoInstall"
InstallDir=$JavaDir/$Bit/jre$ExtendedVersion
Report "$NewInstall" $InstallDir

# package URL depends on architecture
if [ $Bit = 32 ]; then
PackageURL=$(sed -n '/Linux (self-extracting/ s/.*href="\(.*\)" .*$/\1/p;T;q' <$Info)
else
PackageURL=$(sed -n '/Linux x64 (self-extracting/ s/.*href="\(.*\)" .*$/\1/p;T;q' <$Info)
fi

# the bundle id is different for each version and package
BundleId=$(echo $PackageURL | sed -n 's/.*BundleId=\(.*\)$/\1/p')

# we should really only have one package in the TempDir...
rm -f $TempDir/jre*

# check the cache for a suitable file
Report "$CheckingCache"
if [ -f $Cache/installed ]; then
CachedBundleId=$(sed -n '3p' <$Cache/installed)

# first compare bundle ids
Report "$BundleCheck" "$BundleId" "$CachedBundleId"
if [ "$BundleId" = "$CachedBundleId" ]; then
CachedPackage=$(sed -n '4p' <$Cache/installed)

# then check the checksums
if [ "$(sum $Cache/$CachedPackage)" = "$(sed -n '5p' <$Cache/installed)" ]; then
Report "$FromCache" $CachedPackage
cp -af $Cache/$CachedPackage $TempDir/$CachedPackage
PackageName=$TempDir/$CachedPackage
else
Report "$WrongPackage" $CachedPackage
fi
fi
fi

# download if nothing suitable in cache
if [ -z $PackageName ]; then
Report "$DLBinary" $PackageURL
wget $WGetOptions -P $TempDir --trust-server-names $PackageURL || FatalError "$BinaryFailed"

# what is retrieved can have a query string tagged onto the name...
RawPackageName=$(ls $TempDir/jre*)
PackageName=${RawPackageName%%.bin*}.bin
if [ "$RawPackageName" != "$PackageName" ]; then
Report "$CleaningUp" $PackageName
mv "$RawPackageName" $PackageName
fi
fi

Report "$Unpacking"
cd $JavaDir/$Bit
rm -fr $InstallDir

# only switch output depending on logging - no output to screen
[ $Log = 0 ] && UnpackOut='/dev/null' || UnpackOut="$LogFile"
sh $PackageName >>$UnpackOut || FatalError "$UnpackFailed"
[ ! -d "$InstallDir" ] && FatalError "$WrongName"

PluginFull=$InstallDir/lib/$Architecture/$PluginLeaf
Report "$FullPathName" $PluginFull
[ ! -f "$PluginFull" ] && FatalError "$NoPlugin"

# install en set alternatives for all the Java tools
Report "$SetAlts"
for Item in $JavaTools; do
Report "$DoItem" $Item
unset Slave || true
[ -e "$InstallDir/man/man1/$Item.1" ] && gzip $InstallDir/man/man1/$Item.1
[ -e "$InstallDir/man/man1/$Item.1.gz" ] && Slave="--slave /usr/share/man/man1/$Item.1.gz $Item.1.gz $InstallDir/man/man1/$Item.1.gz"
# update-alternatives --install /usr/bin/$Item $Item $InstallDir/bin/$Item $Priority $Slave
# update-alternatives --set $Item $InstallDir/bin/$Item
done

# build the binary format specification file if necessary
Report "$SetBinFormat"
if [ ! -f $InstallDir/lib/jar.binfmt ]; then
echo "package $BinFmtPackage\ninterpreter $InstallDir/lib/jexec\nmagic PK\x03\x04" >$InstallDir/lib/jar.binfmt
fi
# update-alternatives --install /usr/bin/jexec jexec $InstallDir/lib/jexec $Priority --slave /usr/share/binfmts/jar jexec-binfmt $InstallDir/lib/jar.binfmt

Errors=$(tempfile)

# register binary format - ignore errors because the alternative may already be registered by another runtime
if which update-binfmts >/dev/null && [ -r /usr/share/binfmts/jar ]; then
if ! update-binfmts --package $BinFmtPackage --import jar > $Errors; then
ReportCat $Errors
fi
fi

# activate class data sharing - ignore errors generating classes.jsa
Report "$ClassDS"
rm -f $InstallDir/lib/$Architecture/client/classes.jsa
if ! $InstallDir/bin/java -client -Xshare:dump -Xmx256m -XX:PermSize=128m > $Errors; then
rm -f $InstallDir/lib/$Architecture/client/classes.jsa
ReportCat $Errors
fi

rm -f $Errors

# install the plugin
Report "$SetPlugin"
for Item in $BrowserDirs; do
Report "$DoItem" $Item
if [ $Item = xulrunner-addons ]; then
Browser=xulrunner-1.9
else
Browser=$Item
fi
# update-alternatives --quiet --install /usr/lib/$Item/plugins/libjavaplugin.so $Browser-javaplugin.so $PluginFull $Priority
done

# remove any old installations from /opt
for Item in $(ls $JavaDir/$Bit); do
if [ -d $JavaDir/$Bit/$Item ] && [ "$Item" != "jre$ExtendedVersion" ]; then
Report "$RemoveOld" $Item
rm -fr $JavaDir/$Bit/$Item
fi
done

# move a newly downloaded file to the cache
if [ "$BundleId" != "$CachedBundleId" ]; then
mkdir -p $Cache
CachedPackage=$(basename $PackageName)
Report "$ToCache" $Cache/$CachedPackage
Sum=$(sum $PackageName)
mv -f $PackageName $Cache/$CachedPackage

# store an info file called installed alongside it with six fields/lines:
# timestamp, version, bundle id, package name, checksums, install directory
echo "$(date --rfc-3339=s)\n$Version\n$BundleId\n$CachedPackage\n$Sum\$InstallDir" >$Cache/installed
fi

;;

2) # uninstall - can be called from prerm remove|upgrade|deconfigure
Report "$Selected2"

InstallDir=$(sed -n '6p' <$Cache/installed)
PluginFull=$InstallDir/lib/$Architecture/$PluginLeaf

for Item in $BrowserDirs; do
if [ $Item = xulrunner-addons ]; then
Browser=xulrunner-1.9
else
Browser=$Item
fi
update-alternatives --quiet --remove $Browser-javaplugin.so $PluginFull
done

rm -f $InstallDir/lib/i386/client/classes.jsa

if [ "$Phase" = "" ] || [ "$Phase" = "remove" ] || [ "$Phase" = "deconfigure" ]; then
for Item in $JavaTools; do
update-alternatives --remove $Item $InstallDir/bin/$Item
done

if which update-binfmts >/dev/null; then
# try to remove and ignore the error
if [ -e /var/lib/binfmts/$BinFmtPackage ]; then
update-binfmts --package $BinFmtPackage --remove jar /usr/bin/jexec || true
fi
fi

update-alternatives --remove jexec $InstallDir/lib/jexec
fi

###### feitelijk opruimen van pakket nog toevoegen ######

;;

*) echo "$Syntax"
exit 1

;;

esac

Report "$Stopping" "$(date --rfc-3339=s)"


[Pjotr]

Bedankt voor de tussentijdse melding! Ik kan het niet beoordelen (ik mis de benodigde kennis), maar zo te zien heb je al veel werk gedaan. 

Het aardige is, dat het werk dat je doet, van belang is voor vele distributies. Alle Debian-gebaseerde distro's, inclusief Debian zelf, kunnen hier straks van profiteren. Kortom: een belangrijke en eervolle klus.

[Johan van Dijk]

Goed bezig
Heb je een template voor zulke scripts, of schud je dit zo uit de losse mouw? Het ziet er in ieder geval al goed uit.

Wat vragen/suggesties voor je script:
Je kiest voor #!/bin/sh -e aan het begin van het script, om later weer workarounds te gebruiken omdat /bin/sh in de ene distro bash is, en in de andere dash. Als het goed is kan je ook /bin/bash gebruiken, dat zou altijd bash moeten zijn. Of is er een andere specifieke reden dat je voor /bin/sh kiest?

In plaats van af gaan op wat voor kernelversie er draait, zou je ook af kunnen gaan op wat voor soort pakketten dpkg wil installeren. Dit kan via dpkg --print-architecture
Mocht je vreemde systemen hebben met een 64-bits kernel maar 32-bits userspace (ja die zijn er), dan hou je je Java  architectuur gelijk aan de architectuur van de andere pakketten op het systeem.
Een command-line switch om het te overriden zou ook handig kunnen zijn (32-bits Java forceren op 64-bits systeem bijv.)

Voor het uizoeken welke command-line opties er meegegeven zijn zou je getopts kunnen gebruiken.
Zie hier: http://tldp.org/LDP/abs/html/internal.html#EX33 (uitleg staat net iets boven het voorbeeld)
getopt (zonder de s) zou ook kunnen: http://tldp.org/LDP/abs/html/extmisc.html#GETOPTY

[grizzler]

Goed bezig
Heb je een template voor zulke scripts, of schud je dit zo uit de losse mouw? Het ziet er in ieder geval al goed uit.

Dank je. Ik heb intussen aardig wat scripts geschreven en meestal trek ik daar wat bruikbare stukken uit. In dit geval ben ik begonnen met een vrijwel leeg document en heb ik eerst de op de /opt-installatie gerichte onderdelen geschreven. Vervolgens de {post|pre}{inst|rm} scripts van de sun-java6-pakketten doorgenomen om te kijken wat die allemaal doen. Dat was overigens niet zonder meer over te nemen, omdat die scripts altijd worden aangeroepen door dpkg en dit script ook zelfstandig moet kunnen draaien.

Wat vragen/suggesties voor je script:
Je kiest voor #!/bin/sh -e aan het begin van het script, om later weer workarounds te gebruiken omdat /bin/sh in de ene distro bash is, en in de andere dash. Als het goed is kan je ook /bin/bash gebruiken, dat zou altijd bash moeten zijn. Of is er een andere specifieke reden dat je voor /bin/sh kiest?

Min of meer het idee 'als de Debian ontwikkelaars het doen, zal het wel voordelen hebben'. 
Uit een korte steekproef een tijd geleden bleek dat vrijwel alles wat met de distributie meekomt sh gebruikt. Ik denk dat een van de achterliggende gedachten is, dat dash -sinds jaren de standaard shell voor Debian en Ubuntu- een flink stuk 'lichter' is dan bash. Dat sprak me aan.

In plaats van af gaan op wat voor kernelversie er draait, zou je ook af kunnen gaan op wat voor soort pakketten dpkg wil installeren. Dit kan via dpkg --print-architecture
Mocht je vreemde systemen hebben met een 64-bits kernel maar 32-bits userspace (ja die zijn er), dan hou je je Java  architectuur gelijk aan de architectuur van de andere pakketten op het systeem.

Ga ik aanpassen. Dank voor de tip.

Een command-line switch om het te overriden zou ook handig kunnen zijn (32-bits Java forceren op 64-bits systeem bijv.)

Had ik ook al aan gedacht, maar ik wilde eerst even kijken wat daar dan voor 'bescherming' omheen moest. 32-bits op 64-bits is niet zo'n probleem. Andersom wordt rommelig.

Voor het uizoeken welke command-line opties er meegegeven zijn zou je getopts kunnen gebruiken.
Zie hier: http://tldp.org/LDP/abs/html/internal.html#EX33 (uitleg staat net iets boven het voorbeeld)
getopt (zonder de s) zou ook kunnen: http://tldp.org/LDP/abs/html/extmisc.html#GETOPTY

Daar was ik aanvankelijk mee begonnen, maar ik kreeg een paar foutmeldingen niet weg. Omdat ik op dit moment niet zo veel tijd vrij kan maken voor dit project, leek het me beter even over te stappen op iets dat wel gelijk werkte.

[h2o]

Bedankt voor de tussentijdse melding! Ik kan het niet beoordelen (ik mis de benodigde kennis), maar zo te zien heb je al veel werk gedaan.  

Het aardige is, dat het werk dat je doet, van belang is voor vele distributies. Alle Debian-gebaseerde distro's, inclusief Debian zelf, kunnen hier straks van profiteren. Kortom: een belangrijke en eervolle klus.

Ik heb zojuist op mijn Debian Squeeze laptop gekeken, maar ik gebruik helemaal SUN-java maar openjdk. Nu zie ik weliswaar die Sun 2.26 dingen staan, maar ik vraag mij af of Debian dat überhaupt wel gebruikt? En ook waarvoor dan wel?
Ik zal eens een vraag op het Debian forum droppen of er bij Debian wel of niet gebruik wordt gemaakt van die SUN Java dingen?

Debian kennende doen zo het liefst zo weinig mogelijk zaken met closed source zaken. Hier wat Java stof voor Debian: http://wiki.debian.org/Java

[Johan van Dijk]

Het bugrapport van Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645881

[grizzler]

Laten we in ons enthousiasme om een oplossing voor dit probleem aan te dragen vooral de realiteit niet uit het oog verliezen. De kans dat dit script/pakket door alle betrokken partijen wordt geadopteerd is niet zo bijster groot. Linux Mint? Mogelijk. Ubuntu? Mwah. Geen idee, eigenlijk. Debian? No ******* way!

Debian heeft behoorlijk starre opvattingen over 'non free' zaken. Ik denk dat men daar allang blij is dat ze nu eindelijk van Oracle's Java af kunnen komen. Op een achterdeurtje om het toch weer binnen te halen, zitten ze echt niet te wachten.

Over de distributie van dit spul heb ik eigenlijk nog niet eens nagedacht. Via Mint lijkt me nog de beste kans hebben. Of zelf iets opzetten als 'de community'?

[Pjotr]

Over de distributie van dit spul heb ik eigenlijk nog niet eens nagedacht. Via Mint lijkt me nog de beste kans hebben. Of zelf iets opzetten als 'de community'?

Kan zelfs allebei tegelijk.... Je kunt het aanbieden aan Mint, in het betreffende Launchpad-draadje. En tevens zelf een PPA ervoor maken. Dat wordt dan een PPA die ik wel ga gebruiken in mijn systemen. 

[h2o]

Zelf heb ik toch wel een behoorlijk ingewikkelde Debian installatie op mijn laptop staan (Openbox, XFCE, KDE4 met allerlei zaken als Libreoffice, Iceweasel, Multimedia), maar dat volstaat prima met Openjdk. Waarom Ubunty en Linux Mint het dan wel gebruiken (SUN Java) is mij een raadsel als er een goed werkend opensource alternatief is.

[Johan van Dijk]

Ubuntu gebruikt standaard ook gewoon OpenJDK hoor
Alleen sommige dingen werken niet helemaal lekker in OpenJDK, vandaar dat sommigen dus de Sun Java installeren.

[grizzler]

Net even hoofdstukken 5, 6 en 7 van de Debian Policy Manual opnieuw bestudeerd en aan de hand daarvan wat zaken gewijzigd in het controlbestand van het scriptpakket. Pakketje aangemaakt en via mijn private repository aangeboden aan Synaptic. Die wil nu alleen de sun-java6-pakketten verwijderen en gaat niet proberen allerlei OpenJDK-gerelateerde pakketten op te dringen (dat gebeurde woensdag toen ik het sun-java6 spul wilde verwijderen). Ik heb dus kennelijk iets goed gedaan. 

So far so good. Nu eerst alle losse eindjes wegwerken en daar heb ik vanavond geen zin meer in en de komende dagen geen tijd voor. Hoe dan ook, ergens volgende week zal een en ander waarschijnlijk wel in de alpha/beta-testfase terechtkomen.

[Pjotr]

Uiteraard stel ik me beschikbaar als tester.