Autopackage, moet het groot geimplementeerd worden?*

[BHQ]

Allereerst, zie: http://autopackage.org/
Dit is een vrij simpele package manager die automatisch dependencies checkt. Er zijn echter nog wat problemen (imho):

1) Softwaremakerts zo ver krijgen files in .package te distru'en, of een 'converter' schrijven.
2) De implementatie in distro's.

Hoe denken jullie er over? Ik denk dat het een vrij mooi en handig stukje software is.

[M@rijn]

Ik vind het er wel goed uitzien, het idee er achter is top, mij lijkt het het beste om 1 binaire standaard en 1 source standaard te hebben. de .package voor Red Hat / Ubuntu / Debian etc. etc. en bijv. .ebuild voor Gentoo, LFS etc. etc.

[Nakebod]

Zit er niet echt op te wachten, nog een systeem.
Debian heeft apt-get met .deb, ideaal.
Gentoo heeft geloof ik emerge, geen ervaring mee, zover ik weet werkt dat ook erg lekker.
Voor RPM heb je geloof ik ook een apt versie, apt-rpm ofzo, ik verwacht dezelfde werking als apt-get.
Dan mis ik er vast nog wel een aantal, bijvoorbeeld grafische update van Fedora enz.
Daarnaast heb je nog vaak bin/sh installers, de grotere pakketten hebben vaak zelf wel een simpel systeem die checkt of alles aanwezig is. (Bijv Plesk weet ik die dat doet.)

Dus, idee is leuk, alleen de meeste distro's hebben al een systeem/afgeleid van een ander systeem.
Ik ga het zelf niet gebruiken, zolang Debian apt heeft, en dat zal op termijn niet zo heel snel veranderen verwacht ik.

[_JGC_]

Als ik LFS zou draaien, zou ik het misschien overwegen. Maar waarom autopackage als je ook RPM, DEB oid hebt. Zo'n autopackage ding wordt AFAIK alles statisch in gelinkt, dat kan je met een RPM ook doen. Op dat moment heb je dan een RPM die op elke RPM distro zou moeten werken.

[RagaBaSH]

ziet er leuk uit, ik denk dat dergelijke implementatie van software goeie ogen gooit als het gaat om het "feasable" maken van linux voor een beginnende gebruiker. Zeker de grafische component heeft wat leuks.
Waar ik bang voor ben is dat het een beetje mosterd na de maaltijd is, meeste distro's hebben al een package manager (PM), deze is verbonden aan een door HUN onderhouden package-repository, wat eigenlijk betekend dat de eigenaar van een distro ook precies weet welke apps er via hun PM geinstalleerd (en dus gesupport) kunnen worden.
Door de introductie van een cross-platform niet distroafhankelijke PM heb je al snel het probleem dat niets meer ondersteund is. (iets wat voor Jan met de Pet wel degelijk belangrijk is).

De commandline interface lijkt me niet nuttig om je mee bezig te houden. Er zijn al genoeg PM's die hun roots in de CLI vinden. Het lijkt me dat een gevestigd programma een grotere basis heeft om uit te putten (iets wat belangrijker is), bovendien zijn de gebruikers die van CLI's gebruik maken genoeg op de hoogte om ook een distro te kiezen waar een door hun geprefereerde PM in zit.

offtopic:
geimplimiteerd --> geimplementeerd

[zomertje]

Met het komen tot 1 standaard zou voor Linux echt veel bereikt kunnen worden. Als tenminste uiteindelijk het grote publiek aan de Linux moet, dan is duidelijkheid en eenvormigheid erg nuttig. Hooguit een paar distro's om uit te kiezen, en niet een wirwar van systemen en de daarbij behorende tig verschillende distributies. En als we niet uitkijken dan wint niet de beste maar degene met de beste marketing.

[tomato]

In het Belastingdienst topic van laatst heb ik het een en ander gezegd over waarom Autopackage wat mij betreft geen goed idee is (en al helemaal geen vervanger kan zijn voor bestaande packagemanagers, dat geven zelfs de Autopackage developers wel toe).

[Cyphax]

Hrm autopackage. Het is voor zover ik weet een nieuw packagemanagement systeem. Daar ben ik toch niet zo gek op. De meeste distro's zullen zo 2 packagemanagement systemen gaan hebben. Ik zie Patrick Volkerding tgz echt niet vervangen door autopackage, zelfde geldt voor de maintainers van Debian. Ik heb liever een wrapper die autopackages voor mij omzet naar tgz, of .deb, net afhankelijk van welke distro ik gebruik. Dan zou het zoooo veel sneller geaccepteerd worden.

Dit is eigenlijk mijn mening. Proberen 1 packagemanagementsysteem te maken is nu volgens mij veel te laat. Het lijkt me slimmer een brug te slaan tussen de systemen die bestaan (en zichzelf allang bewezen hebben).

[tomato]

Bedenk wel dat Autopackage helemaal niet bedoeld is als ultieme packagemanager en vervanger van apt/rpm/whatever. Dus deze discussie (zoals hij nu gaat) is misschien een klein beetje misplaatst.

[Verwijderd]

Autopackage is naar mijn mening geen goed idee

• Veiligheid, distributies signeren en verifieren automatisch de handtekening van hun pakketten voordat ze gaan installeren (publiek key stond al op de originele CD). Bij losse software van diverse bronnen kan er makkelijk(er) gerommeld worden onderweg
• Eigenlijk wil je de packages compileren op hetzelfde systeem als waarop je het gaat gebruiken (bijvoorbeeld omdat je "fortify source" dingen van GCC wilt gebruiken.
• Als er een library problemen heeft wil je niet het hele package opnieuw downloaden of beschikbaar stellen (en wie gaat dat allemaal controleren/bijhouden?), dan wil je alleen de library updaten.

Het is leuk als je wat software wilt proberen die nog niet voor je distributie beschikbaar is, verder niet. Dit is sowieso niet iets wat beginnende gebruikers moeten/willen doen dus is de markt van Autopackage wel erg beperkt...

[eghie]

Dit was mijn reactie in een ander topic op Autopackage: Eghie in [ALG] gamen onder Linux

Voor gebruiksvriendelijkheid en om 1 standaard aan te houden lijkt het mij een goed product.

[Verwijderd]

zomertje schreef op vrijdag 02 december 2005 @ 10:56:
En als we niet uitkijken dan wint niet de beste maar degene met de beste marketing.

Ik wil best als de Gentoo posterboy fungeren, want dat is uiteraaaaaaaaaaaaard de beste distro. Goh wat zou ik toch zonder al mijn config tweaking moeten

[Verwijderd]

Verwijderd schreef op vrijdag 02 december 2005 @ 13:07:
Autopackage is naar mijn mening geen goed idee

• Veiligheid, distributies signeren en verifieren automatisch de handtekening van hun pakketten voordat ze gaan installeren (publiek key stond al op de originele CD). Bij losse software van diverse bronnen kan er makkelijk(er) gerommeld worden onderweg
• Eigenlijk wil je de packages compileren op hetzelfde systeem als waarop je het gaat gebruiken (bijvoorbeeld omdat je "fortify source" dingen van GCC wilt gebruiken.
• Als er een library problemen heeft wil je niet het hele package opnieuw downloaden of beschikbaar stellen (en wie gaat dat allemaal controleren/bijhouden?), dan wil je alleen de library updaten.

Het is leuk als je wat software wilt proberen die nog niet voor je distributie beschikbaar is, verder niet. Dit is sowieso niet iets wat beginnende gebruikers moeten/willen doen dus is de markt van Autopackage wel erg beperkt...

precies!
Maar het lijkt mij wel handig om commerciele/betaalde software mee te verspreiden. Ook is het denk ik handig als een maker van software/spel zo'n Autopackage op zijn site heeft voor distributies die die software niet in hun repotoires hebben(zoals ubuntu met veel spellen).

[Borromini]

Het is leuk als toetje, als noodoplossing wanneer er geen native pakket beschikbaar is.

[FooBarWidget]

Laat ik me eerste voorstellen: ik ben een van de developers van autopackage. Jawel, ik spreek Nederlands. Ik zie dat er veel misverstand is rond autopackage.

Ten eerste: het doel van autopackage is niet om een all-your-base-are-belong-to-us package manager te maken die alles doet. Het is niet ons doel om RPM/DEB te vervangen. Het is ons doel om softwareinstallatie voor desktop Linux gemakkelijker te maken. Let op het woord desktop (en niet server).

Dat RPM/DEB/Ebuild/etc al bestaat en waarom autopackage dan nog nodig is, is een veel voorkomende vraag. Kijk eens rond op wat Linux forums en je ziet dat vandaag, December 2005, mensen nog steeds klagen over softwareinstallatie op Linux! Een van mijn klasgenoten heeft recentelijk een bekende Linux distro geinstalleerd, en hij klaagt dat softwareinstallatie op Linux "fucking moeilijk" is. Conclusie: RPM/DEB/Ebuild/etc (ik wil dit niet steeds overnieuw typen dus vanaf nu zeg ik "RDE") lossen niet alle problemen rond softwareinstallatie op.

Het grootste probleem met RDE is dat ze distributie-afhankelijk zijn! Als je een RPM maakt voor Fedora 4 dan kun je met vrij veel zekerheid zeggen dat ie niet zal werken op bijvoorbeeld Ubuntu of zelfs een ander RPM-distributie als SuSE. Ditto voor andere RDEs. Dit is:
1. Zeer lastig voor gebruikers.
2. Zeer lastig voor developers, die installatie van hun programma zo gemakkelijk mogelijk willen maken voor hun gebruikers. Developers moeten een aparte package voor bijna alle distributies. Als gewone huis-tuin-en-keuken developer is dat haast onmogelijk.
(voordat je yum/apt noemt, lees verder)

Waarom packages niet werken zal ik hier niet uitleggen, dat zijn immers technische details. Als je geinteresseerd ben in ons onderzoek, bekijk dan onze site (met name de Wiki, stukje over binary compatibility). Wel is het zo dat het probleem veel en veel meer is dan de package formaat alleen.

En tadaa - daar komt autopackage binnen. Autopackage is distributie-onafhankelijk. Als je als developer een autopackage maakt dan kan dat geinstalleerd worden op vele distributies. Ook makkelijk voor gebruikers.
Let op dat autopackage veel meer is dan alleen maar alweer-een-nieuw-bestandsformaat. Wij doen ook heel veel onderzoek op het gebied van inter-distro binary compatibility, en voor zover ik weet zijn wij ook de *enige* groep die dat doen. Andere projecten doen dat helemaal niet. Dit maakt ons uniek.

Maar yum en apt (let op! niet verwarren met RPM en DEB!) dan? Ik denk dat het feit dat mensen nog steeds klagen wel duidelijk is dat ze niet alles oplossen. Ik zal wat specifieker zijn over hun problemen. Mensen klagen voornamelijk over:
1. De software die ik zoek is niet in de repository.
2. De software die ik zoek is wel in de repository, maar is veel te oud.
3. De software die ik zoek is wel in de repository, maar doet het niet! *cough* galeon 1.3 Fedora Extras *cough*

De huidige pakketten worden voornamelijk beheerd door 3rd parties (downstream) ipv de developers van de software zelf (upstream).
Uit #1 kun je, met behulp van wat intuitie, de volgende conclusie trekken: het is gewoon onmogelijk om alle software in de wereld in x repositories te zetten, x=aantal distros die bestaan. Je dupliceert alles dan x keer. Dat kan niet tot het oneindige goed gaan.
Ik heb van sommige mensen horen zeggen dat ze hun software willen laten inpakken door een "gekwalificeerde packager", maar aangezien #3 bestaat zijn de packagers duidelijk niet zo gekwalificeerd. En wie kent het programma nou beter? De upstream developers of iemand die het programma zelf niet heeft geschreven? Mike Hearn (wine developer en autopackage developer) heeft in het verleden al geklaagd over mensen die bug reports sturen over wine, terwijl die bugs eigenlijk veroorzaakt worden door wine Ebuilds die niet goed gemaakt zijn.

Conclusie: het is onze filosofie dat de upstream developers zelf ook pakketten moeten leveren. Dat bespaart een hele hoop ellende.

Als er een library problemen heeft wil je niet het hele package opnieuw downloaden of beschikbaar stellen (en wie gaat dat allemaal controleren/bijhouden?), dan wil je alleen de library updaten.

Waarom is dat een probleem van autopackage? Voor de duidelijkheid: autopackages zijn niet statisch gelinkt naar alle dependencies.

Veiligheid, distributies signeren en verifieren automatisch de handtekening van hun pakketten voordat ze gaan installeren (publiek key stond al op de originele CD). Bij losse software van diverse bronnen kan er makkelijk(er) gerommeld worden onderweg.

Je kan ook autopackages ondertekenen met gpg. De signature wordt in een externe file gezet, maar het kan wel. Geintegreerde GPG ondersteuning staat op mijn todo lijst.


Als er nog vragen zijn dan hoor ik het graag.

[FooBarWidget]

Dit is een reply op Test Linux aangifte software van Belastingdienst
Aangezien die topic al zo oud is, en mijn replies op autopackage slaat, zal ik het hier plaatsen.

Overigens kan ik het spul niet installeren. Als ik de installer run, gaat die autopackage installeren, maar die klaagt over het ontbreken van xauth. Ik heb xauth gewoon in /usr/bin staan.

Dat is in de nieuwste versie van autopackage al verhopen. Als je nu de autopackage installeert dan zou ie het gewoon moeten doen.

Ik hoop alleen dat ze zo snel mogelijk van het verschrikkelijke Autopackage af stappen en gewoon packages maken voor een aantal populaire distributies

Daar heb je al meteen het probleem: packages maken. Met autopackage hoef je het maar 1 keer te doen. Als er problemen zijn dan fixen wij dat graag.
Kun je ook precies zeggen wat er zo "verschrikkelijk" aan is?

Ik haat auto-installers, helemaal als ze per se als root willen draaien.

Goed nieuws, want autopackage heeft geen root nodig! Je kan gewoon naar $HOME/.local installeren.

Je weet nooit wat zo'n ding allemaal gaat uithalen met je systeem...

Dit heeft meer te maken met emoties. Wat is er precies mis met autopackage? Wij lossen graag problemen op als ze bestaan. En laat ik je eraan herinneren dan ook RPM/DEBs van alles kunnen doen in hun pre- en postinstall scripts. Of zelfs source tarballs: de configure scripts en Makefiles kunnen ook van alles uithalen!

Trouwens, autopackage is gewoon open source. Je kan onze broncode zo controleren op trojans of andere rare dingen!

Impliciet is het idee hierachter dus dat het packaging werk verplaatst wordt van de package maintainer naar de upstream developer.

Juist. Dat neemt niet weg dat downstream ook packages mogen maken. Maar als upstream developers ook hun eigen packages leveren dat zal dat de boel een stuk makkelijker maken voor iedereen.

Belangrijker nog, packaging betekent niet alleen je .tgz in een .deb gieten, maar ook het embedden van de applicatie in het OS tijdens installatie (menu entries, gconf schema's, etc).

En dat is juist wat autopackage doet: integreren met je desktop. Autopackage is geen tgz met goudverf ofzo. Wij doen heel erg ons best om software zo goed mogelijk te laten integreren in de desktop, op zoveel mogelijk distributies. Probeer maar een RPM/DEB te maken die dat ook kan.

Het lijkt me nu juist geen goed idee de developers de touwtjes in handen te geven. De developer denkt alleen aan zijn eigen software en niet aan jouw systeem.

Kom op, weet je wel wat je zegt? Als een developer boze bedoelingen heeft dan is packaging het minste waar je zorgen over hoeft te maken. Ook als ie geen boze bedoelingen heeft, en gewoon niet geintereseerd is in dat zijn programma op zoveel mogelijk computers draait, dan is ook packaging maar een deel van het probleem. Overigens is dat wel een ERG sterke generalisatie. Ik zal mijn uiterste best doen om mijn gebruikers te helpen.

Packages binnen deze repositories conflicteren niet met elkaar en zijn getest in de opstelling van de distributie.

FooBarWidget in "Autopackage, moet het groot geimplemente..."
Scroll naar beneden, zie probleem #3.

We willen toch niet de Windows cultuur overbrengen naar Linux? Het uitvoeren van een binary is en blijft iets waar je heel voorzichtig mee moet zijn, het brengt per definitie risico's met zich mee. Als eindgebruikers software van de meest obscure websites af gaan halen en dit met een dubbel klik uitvoeren lijkt het eind me zoek.

We willen toch niet de Windows cultuur overbrengen naar Linux? Het uitvoeren van een binary is en blijft iets waar je heel voorzichtig mee moet zijn, het brengt per definitie risico's met zich mee. Als eindgebruikers software van de meest obscure websites af gaan halen en dit met een dubbel klik uitvoeren lijkt het eind me zoek.

Nogmaals: als het programma een trojan is dan maakt packaging echt niet uit! Iemand met kwade bedoelingen kan zijn trojan in een RPM of DEB of zelfs tarball zetten en dan heb je alsnog een probleem. Het afstoten van autopackage maakt het probleem echt niet kleiner. Wat je er wel mee doet is gebruikers moeilijker maken om legitieme software te installeren.

De oplossing van Autopackage is technisch echter niet goed. Er zijn totaal geen garanties meer te geven over de stabiliteit van je systeem als je Autopackage en een package manager van je distributie door elkaar heen gebruikt.

Autopackage is door vele mensen getest op onder andere Fedora, SuSE, Gentoo, Debian, Ubuntu, Mandrake/Mandriva, Slackware, en Arch. Je ziet al, het werkt sowieso op de grote distributies. Wij hebben geen bug reports ontvangen van mensen die zeggen dat hun systeem totaal naar de klote is nadat ze autopackage hebben geinstalleerd. Sterker nog, de meeste feedback van mensen die autopackage gebruiken zijn juist positief. Als het op jouw systeem wel problemen oplevert dan horen wij dat graag en zullen we dat oplossen.


Laatste woord: van wat ik heb gezien berust de meeste kritiek meer op emoties dan op feiten. Nogmaals: als er een probleem is, laat het dan horen, dan lossen wij het voor je op!

[ Voor 7% gewijzigd door FooBarWidget op 05-12-2005 20:03 ]

[tomato]

FooBarWidget schreef op maandag 05 december 2005 @ 19:36:
Ten eerste: het doel van autopackage is niet om een all-your-base-are-belong-to-us package manager te maken die alles doet. Het is niet ons doel om RPM/DEB te vervangen. Het is ons doel om softwareinstallatie voor desktop Linux gemakkelijker te maken. Let op het woord desktop (en niet server).

Ik begrijp niet goed waarom je hier een onderscheid tussen desktop en server noemt. Bedoel je dat het probleem dat Autopackage wil oplossen alleen op de desktop bestaat en niet in serveromgevingen?

Het grootste probleem met RDE is dat ze distributie-afhankelijk zijn! Als je een RPM maakt voor Fedora 4 dan kun je met vrij veel zekerheid zeggen dat ie niet zal werken op bijvoorbeeld Ubuntu of zelfs een ander RPM-distributie als SuSE. Ditto voor andere RDEs.

Dit is een probleem. Je kunt dit probleem proberen te negeren en lekker je eigen gang gaan zonder nog rekening te houden met bestaande systemen. Je kunt ook proberen die probleem in de bestaande systemen op te lossen. Het laatste is wat op dit moment gebeurt in de Debian wereld, waar het probleem uberhaupt pas recent groter wordt.

Zeer lastig voor developers, die installatie van hun programma zo gemakkelijk mogelijk willen maken voor hun gebruikers. Developers moeten een aparte package voor bijna alle distributies. Als gewone huis-tuin-en-keuken developer is dat haast onmogelijk.

Maar het is ook niet de bedoeling, daar hebben we namelijk packagers voor. Hoe je installatie zo makkelijk mogelijk maakt voor gebruikers is iets dat de distributie als beste kan bepalen, zij hebben namelijk met dit probleem te maken voor duizenden software packages.

En tadaa - daar komt autopackage binnen. Autopackage is distributie-onafhankelijk. Als je als developer een autopackage maakt dan kan dat geinstalleerd worden op vele distributies. Ook makkelijk voor gebruikers.

Echt makkelijk (vergeleken bij een klik in de package manager van je distributie) is het natuurlijk nog niet, maar we zijn het er over eens dat Autopackage niet bedoeld is voor de gevallen waarin dit goed gaat.

Maar yum en apt (let op! niet verwarren met RPM en DEB!) dan? Ik denk dat het feit dat mensen nog steeds klagen wel duidelijk is dat ze niet alles oplossen. Ik zal wat specifieker zijn over hun problemen. Mensen klagen voornamelijk over:
1. De software die ik zoek is niet in de repository.

Ik heb weinig recente ervaring met RPM gebaseerde systemen, maar je onderschat denk ik de coverage van bijvoorbeeld Debian's repositories. Vrijwel nooit kom ik het tegen dat er voor een stabiele versie van een applicatie geen DEB package beschikbaar is. Ik ben een flink wat fanatieker computergebruiker dan gemiddeld. Verder kun je altijd een ITP aanvragen.

2. De software die ik zoek is wel in de repository, maar is veel te oud.

Als er een nieuwere versie van een applicatie beschikbaar is, maar niet als package aangeboden wordt is daar meestal een reden voor. In sommige gevallen is die reden gewoon 'nog niet aan toegekomen', dan werkt aanvragen over het algemeen.

3. De software die ik zoek is wel in de repository, maar doet het niet! *cough* galeon 1.3 Fedora Extras *cough*

Dit is niet een probleem inherent aan het repository systeem en kan net zo goed met een Autopackage gebeuren.

De huidige pakketten worden voornamelijk beheerd door 3rd parties (downstream) ipv de developers van de software zelf (upstream).

Dat is omdat we het zo willen, niet omdat upstream de mogelijkheden niet heeft.

Ik heb van sommige mensen horen zeggen dat ze hun software willen laten inpakken door een "gekwalificeerde packager", maar aangezien #3 bestaat zijn de packagers duidelijk niet zo gekwalificeerd.

Dit is natuurlijk onzin . Packagers kunnen dat over het algemeen goed en er is geen enkele reden waarom hierbij fouten gemaakt zouden worden die niet gemaakt worden bij het maken van een Autopackage.

En wie kent het programma nou beter? De upstream developers of iemand die het programma zelf niet heeft geschreven?

Hier hebben we een groot verschil in mening. Ik vind het belangrijk dat een package gemaakt is door iemand die mijn systeem goed kent. Jij vindt het belangrijk dat een package gemaakt is door iemand die de applicatie goed kent.
In de praktijk is het tweede niet zo'n probleem, als er genoeg gebruikers zijn is er altijd wel iemand met genoeg verstand van de applicatie die ook kan packagen. Sterker nog, in een zeer groot deel van de gevallen zijn packagers mede-developer upstream.

Mike Hearn (wine developer en autopackage developer) heeft in het verleden al geklaagd over mensen die bug reports sturen over wine, terwijl die bugs eigenlijk veroorzaakt worden door wine Ebuilds die niet goed gemaakt zijn.

Dat is dan de fout van die mensen (nouja, waarschijnlijk maakt de distributie het niet duidelijk genoeg). Bug reports horen eerst via het systeem van de distributie te gaan (leuk detail is dat de distributies links voor bugreporting daarop kan aanpassen wanneer ze zelf packagen).

(Wine is trouwens een apart geval. Het is absoluut pre-alpha software waar vooral configuratie een ware ramp is. Er is geen enkel package systeem dat daar iets zinnigs van kan maken.)

Je kan ook autopackages ondertekenen met gpg. De signature wordt in een externe file gezet, maar het kan wel. Geintegreerde GPG ondersteuning staat op mijn todo lijst.

Ik ben benieuwd welke ideeen je daarvoor hebt, het lijkt me in het geval van Autopackage geen gemakkelijk taak.


Autopackage heeft wel zijn nut uiteraard, met name in het geval van zeer kleine applicaties die niet door derden gepackaged kunnen worden ivm licentieproblemen.
Ik ben bang dat er te veel energie wordt gestoken in een oplossing voor deze kleine groep gevallen en men uit het oog verliest waar de problemen eigenlijk liggen en opgelost moeten worden. Autopackage is een patch, meer niet.

[Brent]

Je moet Autopackage inderdaad zien als iets dan naast je eventuele distro-specifieke pakketmanager aanwezig is. Zoiets als .MSI als je voor Windows hebt dus.

Met name software die je niet via je repo's zal krijgen kun je dan makkelijk in als autopackage toch installeren zonder te compileren of andere toeren uit te moeten halen. Met name voor commerciele software, die momenteel ondervertegenwoordig is op Linux en al helemaal niet in repo's te vinden zal gaan zijn, is het een uitkomst. BIjvoorbeeld een computerspel, zeg Quake 4. Je gooit de DVD erin, setup.autopackage draait automagisch, of je zoekte even in de root van de CD als je geen autorun hebt, en klik klik klik Quake 4 staat kant en klaar op je computer, of je nu Fedora, Gentoo of Ubuntu draait. Of je download de .autopackage van de laatste Gimp. Uiteraard kan iederen dev het zo aanpakken, en gewoon een .autopackage of z'n website zetten, net zoals die tienduizenden Windows-devvers dat met hun .exe's doen.

Ik vind het een super initiatief en ik hoop dat dit zo snel mogelijk gewoongoed wordt. Weer een bariere weggenomen. Maakt het voor Adobe bijv. een stuk makkelijker en misschien aantrekkelijker Photoshop eens voor Linux los te laten. Gewoon een .autopackage op de CD zetten, ipv stoeien met .rpm/.deb en dan nog steeds niet iedereen kunnen garanderen dat de software uberhaupt installeerd.

[FooBarWidget]

Ik begrijp niet goed waarom je hier een onderscheid tussen desktop en server noemt. Bedoel je dat het probleem dat Autopackage wil oplossen alleen op de desktop bestaat en niet in serveromgevingen?

Dat klopt. Neem nou mensen als een willekeurig iemands oma. Met andere woorden: de gewone gebruiker. Dat is onze doelgroep. Servers worden over het algemeen beheerd door mensen die technisch bekwaam zijn. Die hebben veel en veel minder last van het het installatieprobleem dan doorsnee gebruikers. Het heeft dan ook geen zin om op de server te richten. Mijn vader kan wat Internetten en dat is het een beetje. Ik zie hem echt geen server beheren. Op die mensen richten wij. Dat is belangrijk als je wilt dat Linux ooit slaagt op de desktop.

Je kunt ook proberen die probleem in de bestaande systemen op te lossen.

Dat is helaas in principe niet mogelijk. Er zit veel teveel politiek aan vast. Het is op dit moment gewoon niet mogelijk om Linux-distributies te standaardiseren. Initiatieven als LSB hebben niks nuttigs gedaan. Ja, glibc, X en nog een paar dingen zijn door de LSB "gestandaardiseerd", maar daar heb je op de desktop bijna niks aan omdat 95% van de desktopapplicaties de GNOME of KDE stack gebruiken, die niet gestandaardiseerd zijn. En dan heb je nog het probleem dat distributies niet out-of-the-box LSB-compliant zijn. Bij de meeste distributies wordt LSB-compliance geimplementeerd mbv een add-on package, die vaak niet standaard geinstalleerd is. Ik heb geruchten gehoord over dat Ubuntu zelfs de LSB-package gaan weghalen.

En dus neemt autopackage de andere weg. Als de distros niet aanpassen aan ons, dan moeten wij maar aanpassen aan hen.

Maar het is ook niet de bedoeling, daar hebben we namelijk packagers voor.

Ja, in theorie. Maar aangezien problemen #1, #2 en #3 (zie mijn vorige post) bestaan kun je toch concluderen dat ze niet altijd even goed of even snel hun taken uitvoeren. En bovendien heb je bij vele distributies gewoon niet de luxe dat alles in de repository zit. De repository van Fedora bijvoorbeeld is piepklein vergeleken met Debian. In de praktijk krijg je problemen als je teveel leunt op die packagers.

En dan heb je nog het probleem dan er heel veel werk gedupliceerd wordt. Denk na: als er x programma's bestaan, en y distributies, dan wordt moet je volgens de third-party-packagers-model x*y keer programma's inpakken. Lijkt me niet erg efficient ofwel? Veel distributies hebben gewoon de mankracht niet. Zelfs Debian niet - dat kun je zien aan het feit dat ze outdated pakketten hebben.

vergeleken bij een klik in de package manager van je distributie

Iets over klik: bij klik zetten ze Debian pakketten automatisch om naar klik pakketten. Maar het probleem is dat Debian pakketten gewoon niet ontworpen zijn om distro-onafhankelijk te zijn. Gevolg: Klik werkt maar op een handjevol distributies. Fedora (toch wel een grote distro) bijvoorbeeld wordt niet ondersteund.

Ik heb weinig recente ervaring met RPM gebaseerde systemen, maar je onderschat denk ik de coverage van bijvoorbeeld Debian's repositories

OK laten we voor de discussie ervan uitgaan dat Debian qua pakketten wel perfect is. Maar dan nog zit je met het probleem dat niet iedereen Debian gebruikt. Je kan simpelweg niet tegen iedereen vertellen dat ze Debian moeten gebruiken. Om Linux aantrekkelijk te maken op de desktop moet je simpelweg installatie makkelijk maken op zoveel mogelijk distributies.

Let erop dat mijn nadruk ligt op het aantrekkelijker maken van Linux op de desktop. Dat is het doel van autopackage.

Ik ben bang dat er te veel energie wordt gestoken in een oplossing voor deze kleine groep gevallen

Aangezien er nog zoveel mensen klagen over softwareinstallatie moet je je toch afvragen of die groep echt "klein" is.

Trouwens, autopackage bevat veel scripting-mogelijkheden. De installatie is een script. Dat geeft enorme flexibiliteit. Je kunt je pakket zo programmeren dat ie bij een bepaalde distro iets anders doet (als dat nodig is).
Jij bent van mening dat je beter een aparte package kunt maken voor je eigen distributie omdat je denkt dat een packager jouw systeem beter kent. Maar stel je nou voor dat, in plaats van een programma x keer dupliceren, dat mensen gewoon al hun krachten bundelt in 1 pakket? Werkt een autopackage niet goed op je systeem? Stuur dan een bug report naar upstream, met eventueel een patch voor de autopackage. Dan heb je EN minder duplicatie EN een package die goed werkt op je systeem.

Trouwens, autopackage maakt het heel makkelijk voor developers om allerlei dingen goed te doen zonder dat ze specifieke kennis hebben over de distributie. Bijvoorbeeld menu items, dat is op veel distributies (helaas) anders geregeld. Bij autopackage typ de developer gewoon de command "installMenu foobar.desktop" en autopackage kopieert het automatisch naar de directory die hoort bij de huidige distributie.

[ Voor 15% gewijzigd door FooBarWidget op 05-12-2005 22:48 ]

[tomato]

FooBarWidget schreef op maandag 05 december 2005 @ 19:56:
En laat ik je eraan herinneren dan ook RPM/DEBs van alles kunnen doen in hun pre- en postinstall scripts. Of zelfs source tarballs: de configure scripts en Makefiles kunnen ook van alles uithalen!

Je moet ook voorzichtig zijn met het runnen van code die je zomaar ergens vandaan plukt. Dat geldt inderdaad net zo goed voor RPM en DEB packages als voor Autopackages.
Maar het is ook niet het DEB formaat waar het me om gaat, het is Apt, de package manager die software uit een trusted repository haalt en configuratie, updates, conflicten en dependencies voor je afhandelt en daarmee de stabiliteit van je systeem waarborgt.

Trouwens, autopackage is gewoon open source. Je kan onze broncode zo controleren op trojans of andere rare dingen!

Dat geloof ik wel, maar het ging me natuurlijk om de inhoud van een specifiek Autopackage package dat je ergens op internet vindt en niet om de source code van het Autopackage systeem.

Kom op, weet je wel wat je zegt? Als een developer boze bedoelingen heeft dan is packaging het minste waar je zorgen over hoeft te maken. Ook als ie geen boze bedoelingen heeft, en gewoon niet geintereseerd is in dat zijn programma op zoveel mogelijk computers draait, dan is ook packaging maar een deel van het probleem.

Packaging (en met name opname in een trusted repository) is hier juist wel erg belangrijk. Het betekent een extra veiligheidslaag voor software met je systeem in aanraking komt. Ik heb meer vertrouwen in de makers van mijn distributie dan in de makers van alle mogelijke software die ik gebruik. Dat mijn distributie een package ergens van aanbiedt geeft extra zekerheid dat die software te vertrouwen is en met name de package versie.

Overigens is dat wel een ERG sterke generalisatie. Ik zal mijn uiterste best doen om mijn gebruikers te helpen.

Iedereen heeft toch ook een firewall? Daarmee zeg je toch ook niet dat alle mede-internetgebruikers slecht zijn? Toch is het een goed idee.

Nogmaals: als het programma een trojan is dan maakt packaging echt niet uit! Iemand met kwade bedoelingen kan zijn trojan in een RPM of DEB of zelfs tarball zetten en dan heb je alsnog een probleem. Het afstoten van autopackage maakt het probleem echt niet kleiner.

Dat klopt, losse packages installeren moet je uberhaupt proberen te vermijden. Als je het dan toch moet doen, doe het dan via het package systeem van je distributie. Dan zullen eventuele updates (wanneer de software later wel beschikbaar is in de repository bijvoorbeeld) transparant afgehandeld worden.

Autopackage is door vele mensen getest op onder andere Fedora, SuSE, Gentoo, Debian, Ubuntu, Mandrake/Mandriva, Slackware, en Arch. Je ziet al, het werkt sowieso op de grote distributies. Wij hebben geen bug reports ontvangen van mensen die zeggen dat hun systeem totaal naar de klote is nadat ze autopackage hebben geinstalleerd.

Ik geloof wel dat jullie erg hard je best doen en dat waardeer ik ook wel, maar Autopackage werkt buiten bestaande package managers om en je kunt daarom geen garanties meer geven over de staat van je systeem. Als ik het goed begrijp zijn er plannen om Autopackage intern beter te integreren met bestaande package managers, maar op dit moment is dat niet het geval.

FooBarWidget schreef op maandag 05 december 2005 @ 22:40:
Bedoel je dat het probleem dat Autopackage wil oplossen alleen op de desktop bestaat en niet in serveromgevingen?

Dat klopt. Neem nou mensen als een willekeurig iemands oma. Met andere woorden: de gewone gebruiker. Dat is onze doelgroep. Servers worden over het algemeen beheerd door mensen die technisch bekwaam zijn. Die hebben veel en veel minder last van het het installatieprobleem dan doorsnee gebruikers. Het heeft dan ook geen zin om op de server te richten. Mijn vader kan wat Internetten en dat is het een beetje. Ik zie hem echt geen server beheren. Op die mensen richten wij.

Ik zie hier helaas een argument tegen Autopackage. Een serverbeheerder zal over het algemeen weten wat software doet en kan best eens een .tar.gz ergens vandaan installeren (of het verstandig is is aan de beheerder).
Gebruikers die geen verstand van dit soort zaken moet je die taak uit handen nemen. Het is goed als de distributie de inrichting van je systeem regelt in dit geval. Juist deze gebruiker moet geen applicatie willen installeren die hij ergens gedownload heeft.

Dat is belangrijk als je wilt dat Linux ooit slaagt op de desktop.

Er zijn twee verschillende visies om Linux te laten slagen op de desktop. De een houdt in het aanpassen van Linux zodat het zo veel mogelijk op Windows gaat lijken. Dit is een voorbeeld van die visie. De ander gelooft dat Linux het beter kan dan Windows in plaats van hooguit even goed. Ik zie het niet zwart-wit, de eerste visie is waardevol (Wine past daar in, maar ook cross-platform applicaties als OO.org en Firefox), maar wil je echt iets bereiken dan telt de tweede visie. Onderken dat het Windows model op veel punten niet ideaal is en wil het dus ook niet namaken. Geloof in betere oplossingen.

De repository van Fedora bijvoorbeeld is piepklein vergeleken met Debian. In de praktijk krijg je problemen als je teveel leunt op die packagers.

Dat is een dan een probleem van Fedora en gebruikers en upstream ontwikkelaars moeten daarover klagen. Als dat niet opgelost kan worden is er blijkbaar niet genoeg ruimte voor zo veel package formaten als er nu zijn. De tijd zal leren of er een afvalt. In Debian (en veel derivianten) werkt het prima.

Even voor de duidelijkheid: persoonlijk geloof ik ook niet dat de huidige situatie uiteindelijk stabiel zal blijken. Uiteindelijk zal het zich wel ergens naar toe bewegen, wellicht niet naar iets dat op dit moment bestaat. Ook Apt zal vervangen worden. Naar betere alternatieven moet onderzoek gedaan worden, Nix is een mooi voorbeeld.

Zelfs Debian niet - dat kun je zien aan het feit dat ze outdated pakketten hebben.

In de meeste gevallen bevat een repository bewust niet de laatste versie om stabiliteit te garanderen en dat is iets wat de gebruiker wil. Ja, dit kan conflicteren met de wens om de laatste versies te gebruiken. Maar het is belangrijker om iets te hebben dat werkt dan iets te hebben dat nieuw is.

Aangezien er nog zoveel mensen klagen over softwareinstallatie moet je je toch afvragen of die groep echt "klein" is.

Mijn ervaring is dat het grootste deel hiervan neer komt op een van:

• Men wil een nieuwere versie dan beschikbaar is: hier is meestal een reden voor (bijvoorbeeld een repository freeze die er niet voor niets is natuurlijk).
• Het gaat om alpha-alpha-alpha software: ben je savvy genoeg om dit je systeem aan te doen dan is een .tar.gz geen probleem voor je.
• Men ziet een 'download' sectie op de website staan zonder te weten/checken dat de package manager de software met een muisklik kan downloaden en installeren: de distributie moet duidelijk maken aan de gebruiker hoe software geinstalleerd wordt. Dit zie ik meestal bij gebruikers die geen ervaring hebben met het idee van software repositories.