Linux Foundation är på väg att sätta standarden LSB 4.0 som är tänkt att ena Linuxdistributionerna och göra det enklare för mjukvaruintegratörer att bygga för Linuxbaserade operativ.
Nu ser det äntligen ut som att frågan om Linux paketformat börjat lyftas upp.
LSB-utvecklaren Jeff Licquia har svarat på en läsarreaktion som i ett blogginlägg hävdat att ”LSB suger” eftersom standarden bygger på RPM. (Jag vågar nog gissa på att läsaren William Pitcook är en APT-fanboy precis som jag själv)
I sitt inlägg försvarar givetvis Jeff Licquia standarden de håller på att plocka fram och anger även att RPM är bara ett av flera sätt mjukvaruintegratörerna kan använda sig av när de packar sin mjukvara.
Själv är min åsikt att RPM eller APT är av underordnad betydelse. För användaren är enda skillnaden vilket kommando som används för att installera mjukvaran. Vad jag istället vill ha svar på är hur de tänker lösa det som på Windows kallas för DLL-HELL – d.v.s när program krockar, försöker byta ut varandras filer och språk mixas hej vilt. Jag vill också veta hur LSB 4.0 löser beroenden (package dependencies). APT löser det problemet alldeles utmärkt och jag tar för givet att RPM idag gör det också.
Frågan är bara hur det ska implementeras i LSB. Att installera ett paket utan beroenden är ingen konst, men hur ska det gå till över distributionsgränserna när ditt LSB-paket är beroende av t.ex postgres, radius, apache + andra-paket-du-gjort?
Nu ställer jag frågan direkt till de som arbetar med LSB 4.0 – men även till er läsare. Någon med insyn som kan sprida ljus över nedanstående fråga som jag lämnat i kommentarfältet till Jeff Licquias inlägg?
Hi and thanks for raising this issue.
I’m Niklas Andersson, writing for Swedish netmag TechWorld Open Source.
I’ve worked with Red Hat between versions 4.2 and 8.0 during the time when resolving package dependencies was a head ache at best.
With Debian 3.1 I ran into very few problems and with Ubuntu I haven’t had any issues this far (besides some I’m responsible of myself due to my own bad packaging).
My question is: Has LSB mechanisms for resolving package dependencies in a distribution neutral manner?
Without such mechanism I find it difficult to create a one-size-fits-all-standard.
Me personally think that a common namespace (how packages are named) is more important than RPM vs APT.
Det räcker inte alltid med att lösa beroenden. Det som är installerat måste ju fungera också, och en trasig installation kan passera beroendekontrollen men stoppa hela mjukvaran för att fungera.
I Gnu configure kan man ju skapa tester som inte bara testar om en funktion finns installerat, utan även om den fungerar som avsett.
I rpm så är det upp den som bygger rpm att skriva de macros som behövs för denna kontroll vilket är ganska omständigt när man har många beroenden. Det skulle behövas ett mer standardiserat sätt att utföra denna kontroll på installerade paket.
Anmäl
Nu är det väl egentligen inte RPM vs. APT du menar utan snarare RPM vs. DEB. Mig veteligen fungerar APT även för RPM-paket.
Anmäl
Rogz har helt rätt.. Du jämför äpplen och päron.
Apt är helt enkelt en nivå över rpm och deb och hanterar just beroenden genom att t.ex ladda ner dom från ett repository.
i .deb och .rpm filerna står exakt vilka paket dom beror på, det "enda" apt gör är att läsa den listan, söka igenom sin lista av repositories och ladda ner motsvarande paket från dessa servrar.
Paketmässigt är det ingen större skillnad mellan deb och rpm. Det finns till och med program (alien) som konverterar fram och tillbaka mellan dom.
Det stora problemet är att paket heter olika, är olika paketerade samt olika byggda för olika distributioner. För att lösa det här enorma problemet krävs:
1) Dependencies måste omarbetas så att man inte gör mikroberoenden längre. Ett program ska endast bero på större platformar istället för enskilda paket (tänk "GNOME", "Linux", "KDE", "GTK", "QT" osv. istället för "libgnome-2.5, libglib-2.4, libgtk+-2.4 libwhatever-1.2.3.special" som det är nu).
Det är sen upp till varje distribution att tillhandahålla paket som uppfyller dessa standardiserade platformskrav. För mer exotiska beroenden så behövs en standardiserad namngivning (gtk heter t.ex. libgtk2 i distro och gtk2 i en annan bah!)
2) Binär kompatibilitet måste lösas. I dagsläget är det i princip omöjligt (läs: väldigt tidskrävande och komplicerat) att kompilera ett program på ett system och sen köra det på ett annat utan problem. Setta gäller mellan distributioner men även mellan olika versioner av samma distribution.
LSB är helt enkelt inte tillräcklig för att som tredjepartsutvecklare (både kommerciella ISV’s samt OSS-utvecklare) kunna skriva och packetera program som fungerar på alla (läs: de flesta) distributioner.
Jag är inte säker på att det här problemet går att lösa och jag är ytterst tveksam till att vi kommer se nån revolutionerande ändring under den närmsta tiden… men så har jag också blivit lite cynisk efter flera år i Autopackage projektet där vi jobbat med exakt dessa frågor utan att få nån större respons (förutom negativ förståss
Anmäl
@iso: Tack för ett bra inlägg – det var lite det jag var rädd för. Att LSB inte räcker hela vägen och att organisera/standardisera name space är viktigare än paketformatet RPM eller DEB.
Skit också
Anmäl
"Ett program ska endast bero på större platformar istället för enskilda paket (tänk "GNOME", "Linux", "KDE", "GTK", "QT" osv. istället för "libgnome-2.5, libglib-2.4, libgtk+-2.4 libwhatever-1.2.3.special" som det är nu)."
Jag förstår inte hur det skulle gå till. API:er ändras ju mellan versionerna, så hur skulle ett program kunna bero på en generisk plattform utan att inkludera versionsinformation?
Anmäl
Jäklar vilket tjat om one size fits all. Jag har en lösning: Skit i det! De stora och populära distributionerna av GNU/Linux gör alla ett bra jobb i att distribuera tredjepartsmjukvara som en del av operativsystemet. I det fall jag verkligen måste ha ett Open Suse 10.3-paket installerat i Ubuntu 8.04 Hardy Heron LTS använder jag alien. Funkar det inte installerar jag från källkod. Funkar det inte suckar jag och letar upp ett annat program. Men det händer mig oerhört sällan. Att lägga ner ofantliga resurser på ett one size fits allprojekt är att kasta resurserna i sjön. Man försöker göra ett paradis av ett träsk, men man får aldrig bukt med de stora blodtörstiga råttorna som bor där.
Problemet ni försöker lösa är inte reellt. Det finns olika GNU/Linuxdistributioner av en anledning och det är bra. Vill jag bara ha något som fungerar så kör jag Open Suse, Fedora eller Ubuntu. Vill jag tweaka och tycker att output från gcc är coolt kör jag Gentoo. Vill jag dra min hardcorepersonlighet till det yttersta väljer jag någon av de övriga 495 (eller nåt) GNU/Linuxdistributioner som finns… Eller gör min egen.
En av styrkorna med fri mjukvara är att den i princip är plattformsoberoende. Problemet ni pratar om finns bara i era huvuden. Tänk om – tänk rätt!
Anmäl
För att paket ska bli dist-oberoende så krävs det även att man standardiserar paketen. Beroenden beror nämligen på vilken version av binärer man har kompilerat mot, och det är inget ett paketsystem kan gå runt. Det krävs antingen att man skriver och kompilerar programmen på ett annat sätt, eller så krävs det att man standardiserar vilka versioner man kompilerar mot.
RPM och DEB skiljer sig bara på hur de lagrar informationen internt. Det spelar ingen roll vilken vi standardiserar runt, så länge vi får en standard. APT kan mycket väl överleva även om RPM är standarden för ett paket. Det är förmodligen ganska lätt för debian och ubuntu att byta till RPM. Att däremot byta ut APT är antagligen knepigare eftersom jag skulle gissa på att de har en hel del annan funktionalitet som är beroende av APT och skulle kräva en hel del jobb för att funka med tex YUM.
Anmäl
@Init: naturligvis är platformarna versionstaggade. Så man beror på "Gnome 2.20", "KDE 4.1" osv.
@Johey2: Jag ifrågasätter inte de olika distributionernas vara eller inte vara. Men det måste bli lättare för tredjepartstillverkare att distribuera sina paket till linux. Alla klarar inte av att kompilera själv eller vill/kan inte av någon annan anledning. Kör man t.ex. ubuntu så är man låst vid den version av applikationen som existerade när distributionen släpptes.. kommer en ny version senare så måste du antingen kompilera från källkod, hoppas att någon annan gjort det åt dig (och byggd paket åt just din distribution) eller vänta till nästa release av distributionen. För mig känns det helt galet att behöva uppgradera hela operativsystemet för att jag vill ha en ny version av chatprogrammet…
Det är dessutom orealistiskt att tro att distributionerna kan tillhandahålla alla program i världen. Debian är väl bäst på det, men inte ens dom har allt. Vissa program (läs: ej fria) kan dom inte inkludera pga legala anledningar…
Anmäl
@iso: apt-get update && apt-get install chatprogrammet
En GNU/Linuxdistribution är ofta tänkt att vara en komplett miljö. Det som inte följer med distributionen behöver du inte. Och i de fåtal fall du ändå behöver det, ja då får du plocka fram din kompilator och trollstav.
Som "tredjepartstillverkare" (är inte alla det?) behöver du bara släppa din produkt i form av källkod. Är den så pass bra att någon vill använda den, kommer den snart till "alla" distributioner. Om "tredjepartstillverkaren" väljer att inte släppa källkoden, då har han inte communityts support och får anstränga sig lite själv. Det är priset han får betala för att vara egoist, och det tycker jag är helt rätt.
Kontentan: Jag är emot alla försök att enhetligfiera GNU/Linuxdistributioner och dess paketeringssystem, för det kommer aldrig fungera. Bara skapa mer frustration, så det är bortkastade resurser.
Anmäl