standaardisatie onder linux

[Verwijderd]

Naar aanleiding van een interview met miguel de icaza wat ik laatst las open ik dit topic. In het interview in kwestie vraagt iemand:

Will GNOME implement an API for installers to use? One thing that helps Windows is a common installer so that most software you put on your system is pretty easy to get on. You just click on the executable and then it installs. With GNOME's goal being to make a user-friendly system do you see this as part of that?

Miguel's antwoord:

GNOME has a few applications for attacking this problem (the GIP), but the problem these days is not just being able to easily install applications, the problem is the slight, subtle and tricky fragmentation of the GNU/Linux distributions.

For example, Helix Code is shipping a pre-built GNOME for various platforms. Although we would love to just compile the code in a specific system and have it installed on the other distributions, it is not possible.

Hopefully the effort to create a standard GNU/Linux base will in the future get rid of this problem, but for now, you are right, it is a real problem and the one that might hurt more the deployment of free software.

Also Helix Code has an installer and an updater that we hope in the future will be turned into generic installer/updater programs that other people can use.

(Helix Code is nu Ximian, en die updater is Red Carpet, die er overigens goed uit ziet.)

Het ideale zou zijn om een installer te hebben als Mozilla heeft, type installshield, en dat er dus gewoon een library zou zijn om snel een installer te maken.

Dit kan dus niet door de verschillen tussen linux distributies. Als de belangrijkste distro's allemaal aan de LSB zouden voldoen, zou zoiets toch mogelijk moeten zijn.

Mandrake, Redhat en SuSE zijn al gecertificeerd, en Debian bijna, maar de standaard specificeert RPM, en zij gebruiken DEB. Maar waarom zouden zij niet aan de ontwikkeling van RPM (gewoon free) kunnen meewerken, en als ze het goed genoeg vinden zelf gebruiken?

Is DEB dan echt zo veel beter als RPM? Hier is een vergelijking RPM/DEB, niet alles staat erin natuurlijk, maar ik zie niet bijster veel verschillen.


meer over dit onderwerp

[Verwijderd]

Ik heb weleens nagedacht over de mogelijkheid van een generic installer en hoe die eruit zou moeten zien. In principe is het heel makkelijk als alle applicaties aan de GNU automake/autoconf principes zouden voldoen. Ook met het standaard Makefile systeem zou het bijzonder makkelijk te doen moeten zijn.

Echter, zoals Miguel al aangeeft, vanwege de varieteit per product aan installatiemethodes wordt het wel moeiilijker met het aantal producten dat je wilt supporten. Alleen GNU automake/autoconf based stuff? En compatible met welke versie? Of ook dingen met een zelfgebrouwselde Makefile? En zo ja, hoe interpreteer je die?

Een GUItje die alleen 'make' fork't en verder niks zinnnigs doet heb je nl. ook niet veel aan.

Ach, standaardisatie. Zie mijn reactie in andere topics - leuk voor zolang het noodzakelijk is. Verder zul je niet komen, daar is linux het platform niet voor, vrees ik.

[Verwijderd]

alsof het zo moeilijk is om RTFM te doen.

[VROEM!]

Verwijderd schreef op 15 augustus 2002 @ 18:58:
alsof het zo moeilijk is om RTFM te doen.

Ja dat is het. Ik vind het in vergelijking met windows redelijk irritant dat ik voor elk linux progje dat ik wil installeren 6 textdocumenten moet lezen, helemaal als het niet bij de distributie zat. Windows programma's klik je gewoon een keertje op, je klikt en tikt door een gestandaardiseerd menu dat je gewoon kunt begrijpen omdat ze toch allemaal hetzelfde zijn en je programma loopt.

Ik vind dat ze dat bij linux ook wel wat harder door mogen voeren, en wellicht zelfs overwegen om de windows vragen/menustijl hierin overnemen.

[DGTL_Magician]

Tja, AFAIK gebruiken de grotere distributeurs van Linux software de LOKI installer. Ik weet niet hoe het met dat ding staat na het failliesement van loki, maar IMHO zag dat er goed uit. Makkelijk, vlot en netjes.

[Verwijderd]

Ik heb weleens nagedacht over de mogelijkheid van een generic installer en hoe die eruit zou moeten zien. In principe is het heel makkelijk als alle applicaties aan de GNU automake/autoconf principes zouden voldoen. Ook met het standaard Makefile systeem zou het bijzonder makkelijk te doen moeten zijn.

Echter, zoals Miguel al aangeeft, vanwege de varieteit per product aan installatiemethodes wordt het wel moeiilijker met het aantal producten dat je wilt supporten. Alleen GNU automake/autoconf based stuff? En compatible met welke versie? Of ook dingen met een zelfgebrouwselde Makefile? En zo ja, hoe interpreteer je die?

Een GUItje die alleen 'make' fork't en verder niks zinnnigs doet heb je nl. ook niet veel aan

het gaat hier toch om een grafische installer om voorgecompileerde programma's te installleren en evt. te configureren? leg alseblieft nog wat verder uit waar je het over hebt, een installer die on the fly compileert toch?

Tja, AFAIK gebruiken de grotere distributeurs van Linux software de LOKI installer.

kan zijn, maar niet een beetje off-topic?

alsof het zo moeilijk is om RTFM te doen.

onzin, er zijn ook linux gebruikers die gewoon 'klik en aan de slag' willen doen, zonder een console te openen of een vage/trage rpm installer (kpackage), en zonder de handleiding te lezen. ik heb het hier gewoon over simpele dingen als winex, evolution, gaim, mozilla of openoffice (deze laatste twee hebben het soort installer waar ik het nu over heb), en niet per se over een (mail/web/dhcp/etc.)server, wanneer je helemaal geen gui installer wilt of nodig hebt.

en het is gewoon een alternatief, zodat je geen tgz, deb, rpm en broncode uit hoeft te geven als je iets maakt, maar gewoon een installer en de broncode (zoals bij mozilla). noobs downloaden de installer, hackers downloaden de broncode

[Verwijderd]

Verwijderd schreef op 15 augustus 2002 @ 20:47:
het gaat hier toch om een grafische installer om voorgecompileerde programma's te installleren en evt. te configureren? leg alseblieft nog wat verder uit waar je het over hebt, een installer die on the fly compileert toch?

Inderdaad. Met GNU automake/autoconf (tenminste, de programma's die zich conform deze laten compileren) is het vrij makkelijk. Alle variabelenamen liggen namelijk vast in de Makefile, en dus kun je alle acties die je vanuit de Makefile uithaalt ook net zo goed in een GUI laten uitvoeren. Je krijgt dan (d.m.v. exitcodes van de subprocessen) alle nodige informatie om een GUI bruikbaar en doeltreffend te maken. Als 't fout gaat kun je zeggen wat en waarom en je kunt alle subopties van make (cclean, install, uninstall) in de GUI parsen en uitvoeren. Allemaal zeer makkelijk (en m.i. ook ontzettend nuttig). Hiermee zou een n00b bij wijze van spreken via een click-and-go systeem alles kunnen compileren zonder ook maar 1 commando in te typen. MCSE-for-linux. . (wie gaat de opmerking over de aap maken? )

Een GUI om RPMs of debjes te installen bestaat al - GnoRPM en de .deb variant daarvan.

[Verwijderd]

Een gui maken voor autconf is niet echt 'handig' imho. Je zult altijd kennis nodig hebben om het in een gui goed aan te kunnen geven. Wat wel een goeie mogelijkheid is, is het maken van een wat slimme package-installer. RPM is wat beperkt, omdat je voor iedere mogelijke vorm van installatie een andere rpm nodig hebt. Das heel vervelend, niet omdat de libs non-backwards-compatible zijn maar meer om effiecentie rededen.

Dingen die ene user zoal zou kunnen instellen met een gui zijn '--enable/--with' voor de rest zijn het niet van die spannende dingen. Prefix settings enzo worden al wat lastiger zolang er geen 'standaard' is voor installtie paht's voor applicaties. Een andere groot probleem waar linux mee zit is dat verschillende soort versies van tal van applicaties. Ook de verschillende dependencys zijn 'naar', beter gezegd is dit het grootste probleem voor het maken van een goed pkg systeem.

Kortsamen gevat is het als vlogt.

Ik wil_alles_ updaten .. Je kan niet zeggan van 'nou begin maar bij a --> z enz. Waarom? Doordat we compilen heb je 'last' van depends. Deze moeten op de juiste volgorde ge-compiled worden en we willen er zeker van zijn dat je nieuwe prog gelinked wordt tegen de nieuwste lib die bij het programma hoort.

Dit zal dus inhouden dat _ALS_ ik bijvoorbeeld kde draai en deze compile tegen qt3.0.0 en later update naar qt3.0.5 --> moet ik alles wat tegen qt3.0.0 compiled recompilen. En kun je nagaan wat er gebeurt als ik glibc wil updaten _alles_ opnieuw!!!

Ps. gentoo lost dit op door non-trival dingen in een world file te plaatsen. En hier uit een complete depend tree maakt (-e optie) en hier van de nieuwste versie installed.. niet slecht.. maar ja .. niet echt wat je zoekt denk ik.

Daarnaast is het zo dat het niet eens altijd kan! Niet alle libs zijn 100% compatible (wat wel zo zou horen!).

De enige goeie reden om zoiets op te losen denk ik is dat er inteligente 'build' scripts komen die zich aan een predefined prefix houden en overrule baar zijn. Dit zal echter meer 'know how' vereisen van package makers.

voorbeeld -> need (lib.proga.1.0.so)

het pakket dat deze dus moet providen zal dus iets hebben van:
provide(lib.proga.1.0.so) Dit zal allemaal in een db of zoiets moeten zitten enz.. maar goed ;-) dwaal af..


Voor dat je een GOEIE GUI kan maken moet er eerst een goeie pkg manager komen. en ja tuurlijk is er apt (de beste tot nu toe) en portage, echter hebben deze niet de volledige functionaliteit met wat betreft depends, hmpf.. geen 1 eingelijks komt wel

[Verwijderd]

Artikel over LSB certificering
Dit lijkt nu van de grond te komen doordat er een aantal grote distributies gecertificeerd zijn voor LSB. Ook het United Linux initiatief zal hier vast wel aan voldoen aangezien SuSE dat min of meer als policy heeft. Dat is een stap op weg naar standaardisatie.

[ Voor 0% gewijzigd door Verwijderd op 16-08-2002 04:10 . Reden: url werkte niet, feature van react :) ]

[Verwijderd]

Das heel mooi, maar dit neemt het problemen voor het maken van een UI voor compile dingen niet weg.

[Verwijderd]

Verwijderd schreef op 16 augustus 2002 @ 03:58:
Een gui maken voor autconf is niet echt 'handig' imho. Je zult altijd kennis nodig hebben om het in een gui goed aan te kunnen geven.

Dingen die ene user zoal zou kunnen instellen met een gui zijn '--enable/--with' voor de rest zijn het niet van die spannende dingen. Prefix settings enzo worden al wat lastiger zolang er geen 'standaard' is voor installtie paht's voor applicaties.

Maar die zou je, in een gestandaardiseerde autoconf file, zonder problemen in een GUI kunnen zetten, snap je? En persoonlijk denk ik dat het, als standaard 'pagina' in de installer, op gegeven moment wel zou wennen. "Wil ik openGL? Ja", "Wil ik perfix=/<stanadard_path>? Nee, ik wil ergens anders". Standaard pathetc. ('template) kunnen per distro in /etc/installer.conf geregeld worden (system-wide) of in ~/.installer/config.

Ik denk dat het i.i.g. makkelijk te doen is en dat de gebruiker er vanzelf aan zou wennen. In 9 van de 10 gevallen doe je trouwens toch simpelweg ./configure && make && su -c "make install" (lees: drie keer op next drukken en 1x op OK).

Dit zal dus inhouden dat _ALS_ ik bijvoorbeeld kde draai en deze compile tegen qt3.0.0 en later update naar qt3.0.5 --> moet ik alles wat tegen qt3.0.0 compiled recompilen. En kun je nagaan wat er gebeurt als ik glibc wil updaten _alles_ opnieuw!!!

. . . Lees eens over shared libraries! Dit is je reinste onzin! .

[Verwijderd]

Reinste onzin ? sure dude als jij het zegt.

[Verwijderd]

Verwijderd schreef op 16 augustus 2002 @ 09:25:
[...]


Maar die zou je, in een gestandaardiseerde autoconf file, zonder problemen in een GUI kunnen zetten, snap je? En persoonlijk denk ik dat het, als standaard 'pagina' in de installer, op gegeven moment wel zou wennen. "Wil ik openGL? Ja", "Wil ik perfix=/<stanadard_path>? Nee, ik wil ergens anders". Standaard pathetc. ('template) kunnen per distro in /etc/installer.conf geregeld worden (system-wide) of in ~/.installer/config.

Ik denk dat het i.i.g. makkelijk te doen is en dat de gebruiker er vanzelf aan zou wennen. In 9 van de 10 gevallen doe je trouwens toch simpelweg ./configure && make && su -c "make install" (lees: drie keer op next drukken en 1x op OK).


[...]

Dan zit je met allerlei depends.. dat maakt het voor de user niet makkelijker op..

[Verwijderd]

Verwijderd schreef op 16 augustus 2002 @ 14:54:
Reinste onzin ? sure dude als jij het zegt.

Wt ik bedoel is dat libraries over het algemeen binary compatible zijn. d.w.z, als ik iets tegen Qt-3.0.1 compileer en ikinstalleer daarna Qt-3.0.2, dan werkt het nog steeds.

Dus opnieuw compileren is niet nodig.

[Verwijderd]

Wat jij wil zeggen snap ik prima ;-) maar het is niet altijd zo!!! Dat is het grote probleem. Daarnaast is het zo dat als ik bijvoorbeeld.. euh.

bash ofzo compile dan is die ge-ldd-ed tegen ncurses.1.01.so weet ik veel je snapt wat ik bedoel ;-)

als ik nu dan de nieuwe ncrurses neem (dit is dus echt een lib die erg strek veranderd per keer en vaker niet als wel 100% compat. is) dan moet je dus zorgen dat ie nu linked naar de nieuwste lib voor dat je die er af kanhalen etc.

LibPNG is ook zo'n drama geval. Als de de nieuwe er op zet en de ouder verwijderd.. heb je wel een probleem. Kweet niet meer psies welke versie-> naar versie is .. maar goed. Het komt dus vaak, te vaak voor dat ze niet 100% compatible zijn. Dit soort dingen zou je in een goeie 'install' proggel mee moeten nemen. Het maken van een klik hier voor openGL is leuk om eens te maken .. maar denk niet dat het goed gaat werken zonder dit soort dingen in acht te nemen.

[odysseus]

Verwijderd schreef op 16 augustus 2002 @ 03:58:
Wat wel een goeie mogelijkheid is, is het maken van een wat slimme package-installer. RPM is wat beperkt, omdat je voor iedere mogelijke vorm van installatie een andere rpm nodig hebt. Das heel vervelend, niet omdat de libs non-backwards-compatible zijn maar meer om effiecentie rededen.

Ik wil_alles_ updaten .. Je kan niet zeggan van 'nou begin maar bij a --> z enz. Waarom? Doordat we compilen heb je 'last' van depends. Deze moeten op de juiste volgorde ge-compiled worden en we willen er zeker van zijn dat je nieuwe prog gelinked wordt tegen de nieuwste lib die bij het programma hoort.

Dit zal dus inhouden dat _ALS_ ik bijvoorbeeld kde draai en deze compile tegen qt3.0.0 en later update naar qt3.0.5 --> moet ik alles wat tegen qt3.0.0 compiled recompilen. En kun je nagaan wat er gebeurt als ik glibc wil updaten _alles_ opnieuw!!!

Ps. gentoo lost dit op door non-trival dingen in een world file te plaatsen. En hier uit een complete depend tree maakt (-e optie) en hier van de nieuwste versie installed.. niet slecht.. maar ja .. niet echt wat je zoekt denk ik.

Daarnaast is het zo dat het niet eens altijd kan! Niet alle libs zijn 100% compatible (wat wel zo zou horen!).

De enige goeie reden om zoiets op te losen denk ik is dat er inteligente 'build' scripts komen die zich aan een predefined prefix houden en overrule baar zijn. Dit zal echter meer 'know how' vereisen van package makers.

voorbeeld -> need (lib.proga.1.0.so)

het pakket dat deze dus moet providen zal dus iets hebben van:
provide(lib.proga.1.0.so) Dit zal allemaal in een db of zoiets moeten zitten enz.. maar goed ;-) dwaal af..

Voor dat je een GOEIE GUI kan maken moet er eerst een goeie pkg manager komen. en ja tuurlijk is er apt (de beste tot nu toe) en portage, echter hebben deze niet de volledige functionaliteit met wat betreft depends, hmpf.. geen 1 eingelijks komt wel

Ik denk toch dat het DEB-formaat in combinatie met dpkg en apt alles kan wat jij hier beschrijft. Hoe je erbij komt dat die geen Depends: ondersteunen (of dat niet goed doen) weet ik niet, maar DEB-packages hebben in ieder geval de mogelijkheid tot een Pre-Depends, Build-Depends, Depends en misschien nog een aantal die me niet te binnen schieten. Daarnaast zijn er natuurlijk nog dingen als Suggests: en Recommends:, maar die doen hier minder ter zake. Het is nu al mogelijk om je hele systeem te compileren, aangezien zo'n dependency-tree gewoon uitgerekend kan worden. Onder mijn Debian-installatie kan dat bijvoorbeeld met het commando 'apt-rdepends kdelibs4 | grep Depends | sort | uniq' om te zien welke packages er allemaal afhankelijk zijn van kdelibs4.

Dat library-upgrades voor problemen zorgen kan waar zijn, maar dat zou natuurlijk nooit mogen gebeuren. Als een nieuwe lib niet compatibel is met de oude, dan dient hij een ander versienummer te krijgen, waarna je rustig twee libs naast elkaar kunt draaien. Zie de hele berg libraries in /usr/lib die daarvan gebruik maken met namen als xxx.so.2 en xxx.so.3. Momenteel is het inderdaad zo dat bijvoorbeeld libpng nog wel eens een andere interface krijgt zonder een andere lib te gebruiken, maar dat zijn incidentele fouten, geen structurele fouten.

Het grotere probleem voor installers zit hem denk ik in de verschillen die gebruikt worden bij bijvoorbeeld opstartscripts. Hoe moet je je programma automatisch laten opstarten als je niet weet hoe de opstartscripts op een bepaald systeem in elkaar zitten? Ik denk dat de oplossing daarvoor ligt in het aanmaken van een extra layer, zoals dat nu in Debian al heel veel gebeurt en zoals dat ook in de LSB wordt gedaan als ik het me goed herinner. Denk daarbij aan een commando als 'update-rc.d' dat je nu in distributies kunt aantreffen. Op die manier kun je een duidelijke interface creëeren naar de lowlevel-configuratie van een systeem, dat per distributie verschilt.