.rpm vaiko .deb

Toki nuo osaan. Välillä vain tulee tarve uusimmalle versiolle jostain ohjelmasta. Välillä taas ei välttämätön tarve vaan sellainen, että olisi kiva saada esimerkiksi jokin patchi käyttöön. Tuntuu vain, että Debianin paketointityökaluja on hirveä määrä ja niiden ymmärtäminen on sen vuoksi hankalaa. Onko Fedoralla tai CentOSilla sama tilanne vai onko siellä vähemmän eri työkaluja? Toki se voi kovin pitkän päälle olla huonompi, mutta tuntuu että tätä järjestelmää on hankala hallita.

hgjgjc kirjoitti:

Toki nuo osaan. Välillä vain tulee tarve uusimmalle versiolle jostain ohjelmasta. Välillä taas ei välttämätön tarve vaan sellainen, että olisi kiva saada esimerkiksi jokin patchi käyttöön. Tuntuu vain, että Debianin paketointityökaluja on hirveä määrä ja niiden ymmärtäminen on sen vuoksi hankalaa. Onko Fedoralla tai CentOSilla sama tilanne vai onko siellä vähemmän eri työkaluja? Toki se voi kovin pitkän päälle olla huonompi, mutta tuntuu että tätä järjestelmää on hankala hallita.

"Toki nuo osaan. Välillä vain tulee tarve uusimmalle versiolle jostain ohjelmasta."

Minä vaan painan sitä käyttöjärjestelmän päivitysnappia, olkoot se paketointimekanismi mikä tahansa. Vaihtoehtoisesti lataan ohjelman käyttöjärjestelmän ulkopuolelta valmistajalta jos ei ole missään pakettilähteissä.

"Ero oli sillon yli 10v sitten tosiaan kun apt hoiti kaikki kerralla ja rpm oli yhtä kuin riippuvuushelvetti."

Ei taida johtua mitenkään paketointijärjestelmästä vaan käyttöjärjestelmästä, siinä olevasta alustasta ja siitä miten ne paketit on tehty käyttöjärjestelmälle. Esim. jos teki Red Hat Enterprise 3:lle .rpm paketin silloin 10v sitten, etenkin vielä niin että käänsi jutut LSB kirjastoja vasten mahdollisuuksien mukaan niin eipä siinä mitään ihmeellistä riippuvuushelvettiä ollut.

Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat? Myöskään Sidissä ei ole uudempaa. Mielummin silti asennan ihan oikein tehdyn paketin kuin ./configure; make; make install.. Mielestäni paketinhallinta on yksi oleellisimpia eroja eri distroissa. En missään nimessä väitä, että kaikille se olisi oleellista enkä tiedä onko se edes niin oleellinen, että vaihtaisin. Lähinnä yritän kysellä muiden mielipiteitä siitä, onko RPM:n paketointityökalut millaisia verrattuna DEB-pakettien luomiseen.

Omalla koneellani, joka ei ole kriittisessä käytössä tahtoisin kuitenkin itse helposti tehdä omia päivityksiä tarvitsemiini paketteihin. Debianin systeemeitä olen myös kuullut kehuttavan. Niiden pitäisi automatisoida iso osa tuosta työstä, mutta itse en meinaa päästä niihin sisään, vaikka olen jo joitain kertoja koittanut. Mietin, että onkohan RPM yhtä hankala sisäänpäästävä. Esimerkiksi Arch Linuxissa ja Slackwaressa on todella helposti ymmärrettävä järjestelmä pakettien luomiseen, ei varmasti yhtä "tehokas" kuin Debianissa, mutta juuri sen takia todella helposti ymmärrettävä.

fdgfg kirjoitti:

Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat? Myöskään Sidissä ei ole uudempaa. Mielummin silti asennan ihan oikein tehdyn paketin kuin ./configure; make; make install.. Mielestäni paketinhallinta on yksi oleellisimpia eroja eri distroissa. En missään nimessä väitä, että kaikille se olisi oleellista enkä tiedä onko se edes niin oleellinen, että vaihtaisin. Lähinnä yritän kysellä muiden mielipiteitä siitä, onko RPM:n paketointityökalut millaisia verrattuna DEB-pakettien luomiseen.

Omalla koneellani, joka ei ole kriittisessä käytössä tahtoisin kuitenkin itse helposti tehdä omia päivityksiä tarvitsemiini paketteihin. Debianin systeemeitä olen myös kuullut kehuttavan. Niiden pitäisi automatisoida iso osa tuosta työstä, mutta itse en meinaa päästä niihin sisään, vaikka olen jo joitain kertoja koittanut. Mietin, että onkohan RPM yhtä hankala sisäänpäästävä. Esimerkiksi Arch Linuxissa ja Slackwaressa on todella helposti ymmärrettävä järjestelmä pakettien luomiseen, ei varmasti yhtä "tehokas" kuin Debianissa, mutta juuri sen takia todella helposti ymmärrettävä.

"Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat?"

Vähän kiinnostaa tietää tarkemmin, että mikä ohjelma mahtaa olla kyseessä? Ja mikä toiminto on se tarve? Todennäköisesti teet jotain väärin mutta en tiedä vielä mitä.

Normaalisti käytetään niitä ohjelmia jotka on käyttöjärjestelmässä valmiina koska ne on parhaiten testattu ja helpointa ylläpitää. Jos toiminto on sellainen joka ei ole käyttöjärjestelmässä valmiina niin sitten normaalisti ostetaan/ladataan asennuspaketti ohjelmiston valmistajalta, ja käyttöjärjestelmä on sitten alusta tälläiselle lisäpalikalle.

Jos sitten on kyse jostain avoimen lähdekoodin jutusta jossa käyttöjärjestelmässä on versio 88 ja kehittäjältä löytyy versio 95 pelkkänä lähdekoodina, niin sittenhän tilanne on se, että kyseinen ohjelma ei ole vielä edes valmis!

Ohjelmahan on valmis sitten kun siitä on yhteensopivaksi testattu ja valmiiksi käännetty paketti alustalle. Avoimen lähdekoodin ohjelmistoissa on tavallista, että kehittäjä puskee uutta versiota ulos ns. ketterän mallin mukaisesti, uutta versiota tiheään tahtiin ja homma elää kokoajan, mutta ne eivät ole valmiita vaan se tuotteistus jätetty sitten käyttöjärjestelmän toimittajalle ja siinä sitten tulee useampiportainen testaus ennen kuin on se on oikeasti valmis.

m-kar kirjoitti:

"Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat?"

Vähän kiinnostaa tietää tarkemmin, että mikä ohjelma mahtaa olla kyseessä? Ja mikä toiminto on se tarve? Todennäköisesti teet jotain väärin mutta en tiedä vielä mitä.

Normaalisti käytetään niitä ohjelmia jotka on käyttöjärjestelmässä valmiina koska ne on parhaiten testattu ja helpointa ylläpitää. Jos toiminto on sellainen joka ei ole käyttöjärjestelmässä valmiina niin sitten normaalisti ostetaan/ladataan asennuspaketti ohjelmiston valmistajalta, ja käyttöjärjestelmä on sitten alusta tälläiselle lisäpalikalle.

Jos sitten on kyse jostain avoimen lähdekoodin jutusta jossa käyttöjärjestelmässä on versio 88 ja kehittäjältä löytyy versio 95 pelkkänä lähdekoodina, niin sittenhän tilanne on se, että kyseinen ohjelma ei ole vielä edes valmis!

Ohjelmahan on valmis sitten kun siitä on yhteensopivaksi testattu ja valmiiksi käännetty paketti alustalle. Avoimen lähdekoodin ohjelmistoissa on tavallista, että kehittäjä puskee uutta versiota ulos ns. ketterän mallin mukaisesti, uutta versiota tiheään tahtiin ja homma elää kokoajan, mutta ne eivät ole valmiita vaan se tuotteistus jätetty sitten käyttöjärjestelmän toimittajalle ja siinä sitten tulee useampiportainen testaus ennen kuin on se on oikeasti valmis.

Kyseinen paketti on puhtaasti hupikäyttöön. Kyseessä on open source RTS-peli, spring, joka löytyy pakettivarastoista versiona 88.0. Uusin pelattava versio on kuitenkin 95.0, joka vaaditaan moninpeliin. Yritin sitä toissapäivänä kääntää ja sainkin lopulta jonkinlaisen paketin aikaiseksi. Jälleen kuitenkin meni useita yrityksiä, mm. kääntäminen onnistui, mutta sen jälkeen debuild ajoi joitain testejä, joista läpi meni 12/25 => pakettia ei luotu. Lopulta käskin ohittaa nuo virheet ja jotenkuten toimiva paketti syntyi. Ei tuo työympäristössä mikään tärkeä paketti ole. Kotona omalla koneella sen sijaan, kun se on mahdollista saada toimimaan, niin olisi kiva oppia luomaan noita omia paketteja. Yleisesti lähdekoodista kääntäminen, kun ei ole kovin vaikeaa. Lähinnä jumitan siinä .deb paketin luomisvaiheessa.

Kai sitä voisi kysyä toisenkin kysymyksen: Erilaisia ohjeita löytyy Debianille ihan tuhottomasti, mutta osa niistä on todennäköisesti yksinkertaisesti väärin tai vanhentunut. Mikähän olisi nykyään ajantasalla oleva manuaali pakettien luomiseen? Päivitetäänkö Debianin omaa dokumentaatiota jatkuvasti?

m-kar kirjoitti:

"Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat?"

Vähän kiinnostaa tietää tarkemmin, että mikä ohjelma mahtaa olla kyseessä? Ja mikä toiminto on se tarve? Todennäköisesti teet jotain väärin mutta en tiedä vielä mitä.

Normaalisti käytetään niitä ohjelmia jotka on käyttöjärjestelmässä valmiina koska ne on parhaiten testattu ja helpointa ylläpitää. Jos toiminto on sellainen joka ei ole käyttöjärjestelmässä valmiina niin sitten normaalisti ostetaan/ladataan asennuspaketti ohjelmiston valmistajalta, ja käyttöjärjestelmä on sitten alusta tälläiselle lisäpalikalle.

Jos sitten on kyse jostain avoimen lähdekoodin jutusta jossa käyttöjärjestelmässä on versio 88 ja kehittäjältä löytyy versio 95 pelkkänä lähdekoodina, niin sittenhän tilanne on se, että kyseinen ohjelma ei ole vielä edes valmis!

Ohjelmahan on valmis sitten kun siitä on yhteensopivaksi testattu ja valmiiksi käännetty paketti alustalle. Avoimen lähdekoodin ohjelmistoissa on tavallista, että kehittäjä puskee uutta versiota ulos ns. ketterän mallin mukaisesti, uutta versiota tiheään tahtiin ja homma elää kokoajan, mutta ne eivät ole valmiita vaan se tuotteistus jätetty sitten käyttöjärjestelmän toimittajalle ja siinä sitten tulee useampiportainen testaus ennen kuin on se on oikeasti valmis.

Palstan vakiouuno ei taaskaan ymmärrä kysymystä, ja vastaa tutulla liturgisella paasauksellaan.

dfsdf kirjoitti:

Kyseinen paketti on puhtaasti hupikäyttöön. Kyseessä on open source RTS-peli, spring, joka löytyy pakettivarastoista versiona 88.0. Uusin pelattava versio on kuitenkin 95.0, joka vaaditaan moninpeliin. Yritin sitä toissapäivänä kääntää ja sainkin lopulta jonkinlaisen paketin aikaiseksi. Jälleen kuitenkin meni useita yrityksiä, mm. kääntäminen onnistui, mutta sen jälkeen debuild ajoi joitain testejä, joista läpi meni 12/25 => pakettia ei luotu. Lopulta käskin ohittaa nuo virheet ja jotenkuten toimiva paketti syntyi. Ei tuo työympäristössä mikään tärkeä paketti ole. Kotona omalla koneella sen sijaan, kun se on mahdollista saada toimimaan, niin olisi kiva oppia luomaan noita omia paketteja. Yleisesti lähdekoodista kääntäminen, kun ei ole kovin vaikeaa. Lähinnä jumitan siinä .deb paketin luomisvaiheessa.

Kai sitä voisi kysyä toisenkin kysymyksen: Erilaisia ohjeita löytyy Debianille ihan tuhottomasti, mutta osa niistä on todennäköisesti yksinkertaisesti väärin tai vanhentunut. Mikähän olisi nykyään ajantasalla oleva manuaali pakettien luomiseen? Päivitetäänkö Debianin omaa dokumentaatiota jatkuvasti?

"Uusin pelattava versio on kuitenkin 95.0, joka vaaditaan moninpeliin."

Ööh.. ei se nyt ihan näin mene. Spring on pelimoottori, ja idea on se että sille tehdään pelejä. Se versio mikä on Debianissa on tämä, mikä on käynyt koko integrointi ja testausprosessin ja tälle versiolle kun teet peliä niin se toimii vähintään koko Debianin elinkaaren ajan. Debianissa siis vastataan siitä, että tässä oleva Spring moottorin versio toimii luotettavasti yhteen muun järjestelmän kanssa, eli se on integroitu siihen ja testattu toimivaksi, siis valmis versio.

Tätä ei siis pidä miettiä minkään pelaamisen kannalta vaan pelin tekemisen kannalta Debianille. Debian siis tarjoaa itsessään pelimoottorin mille voi tehdä pelejä.

Jos yrität kääntää uudempaa versiota pelimoottorista Debianillahan niin tämähän on sitten pelinkehitystyötä jos haluat tähdätä peliäsi uudemmalle versiolle pelimoottorista.

Olemassa olevat pelit ovat tietysti myös versioriippuvaisia pelimoottorista, eli voit tietysti porttailla niitä Debianille jos haluat. Kannattaa suunnitella asia niin, että olet sitten pakettien ylläpitäjä niin muutkin saavat hyötyä siitä että näet vaivaa.

Kun siirretään softaa ärjestelmälle niin tässähän tietysti sitten pitää osata tehdä sitä kehitystyötä. Eli jos ei sorsa käänny niin tietysti sitten osataan ottaa se koodi haltuun ja sovittaa toimimaan. Ihan perus ohjelmointityötä. Ei ne ohjelmat tietenkään käänny aina vaan ohjelmistokehittähän hommia on sitten selvittää ne ongelmat ja korjata. Siitähän tässä on kyse, ei mistään paketointijärjestelmästä.

Debianin kehittäjille on kyllä hyvät ohjeistukset olemassa: http://www.debian.org/doc/devel-manuals.en.html

m-kar kirjoitti:

"Uusin pelattava versio on kuitenkin 95.0, joka vaaditaan moninpeliin."

Ööh.. ei se nyt ihan näin mene. Spring on pelimoottori, ja idea on se että sille tehdään pelejä. Se versio mikä on Debianissa on tämä, mikä on käynyt koko integrointi ja testausprosessin ja tälle versiolle kun teet peliä niin se toimii vähintään koko Debianin elinkaaren ajan. Debianissa siis vastataan siitä, että tässä oleva Spring moottorin versio toimii luotettavasti yhteen muun järjestelmän kanssa, eli se on integroitu siihen ja testattu toimivaksi, siis valmis versio.

Tätä ei siis pidä miettiä minkään pelaamisen kannalta vaan pelin tekemisen kannalta Debianille. Debian siis tarjoaa itsessään pelimoottorin mille voi tehdä pelejä.

Jos yrität kääntää uudempaa versiota pelimoottorista Debianillahan niin tämähän on sitten pelinkehitystyötä jos haluat tähdätä peliäsi uudemmalle versiolle pelimoottorista.

Olemassa olevat pelit ovat tietysti myös versioriippuvaisia pelimoottorista, eli voit tietysti porttailla niitä Debianille jos haluat. Kannattaa suunnitella asia niin, että olet sitten pakettien ylläpitäjä niin muutkin saavat hyötyä siitä että näet vaivaa.

Kun siirretään softaa ärjestelmälle niin tässähän tietysti sitten pitää osata tehdä sitä kehitystyötä. Eli jos ei sorsa käänny niin tietysti sitten osataan ottaa se koodi haltuun ja sovittaa toimimaan. Ihan perus ohjelmointityötä. Ei ne ohjelmat tietenkään käänny aina vaan ohjelmistokehittähän hommia on sitten selvittää ne ongelmat ja korjata. Siitähän tässä on kyse, ei mistään paketointijärjestelmästä.

Debianin kehittäjille on kyllä hyvät ohjeistukset olemassa: http://www.debian.org/doc/devel-manuals.en.html

Itseäniähän kiinnostaa tuossa vain se pelaaminen silloin harvoin kuin pelaan. Pelaaminen onnistuu jos onnistun kääntämään sen version, mitä kaikki muut, kuin Debianin käyttäjät käyttävät. Debian ei sitä luonnollisestikaan itse tarjoa, koska Debian ei tee isoja muutoksia paketeille jäädytyksen jälkeen. Eli toisin sanoen siinä olet oikeassa, että Debian toimii kuten sen on tarkoituskin. "Ongelman" aiheuttajahan olen minä itse, kun tahdon muokata Debiania oman mieleni mukaiseksi ja sitä ei luonnollisestikaan suoraan kyetä tarjoamaan. Debianin paketointijärjestelmästä tässä on siinä mielessä kyse, että kyseisen moottorin saan käännettyä ja toimimaan, mutta en saa luotua siitä Debianin pakettia. Tämä tosin johtuu vain omasta osaamattomuudestani. Toisaalta siitähän koko aihe lähti liikkeelle, kun pohdin että ovatko .RPM-pohjaiset jakelut helpompia lähestyttäviä tässä asiassa.

keebsimppelille: Noita paketteja kuitenkin ajan saatossa kerääntyy jonkin verran, ja suurinosa niistä löytyy pakettivarastosta vanhempana versiona. Ihan tuosta syystä tahtoisin tehdä apt:in tietoiseksi noiden pakettien olemassaolosta ja tehdä niistä ihan oikeasti oikein paketoituja paketteja, että pystyisi helposti hallitsemaan rikkomatta koko systeemiä.

m-kar kirjoitti:

"Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat?"

Vähän kiinnostaa tietää tarkemmin, että mikä ohjelma mahtaa olla kyseessä? Ja mikä toiminto on se tarve? Todennäköisesti teet jotain väärin mutta en tiedä vielä mitä.

Normaalisti käytetään niitä ohjelmia jotka on käyttöjärjestelmässä valmiina koska ne on parhaiten testattu ja helpointa ylläpitää. Jos toiminto on sellainen joka ei ole käyttöjärjestelmässä valmiina niin sitten normaalisti ostetaan/ladataan asennuspaketti ohjelmiston valmistajalta, ja käyttöjärjestelmä on sitten alusta tälläiselle lisäpalikalle.

Jos sitten on kyse jostain avoimen lähdekoodin jutusta jossa käyttöjärjestelmässä on versio 88 ja kehittäjältä löytyy versio 95 pelkkänä lähdekoodina, niin sittenhän tilanne on se, että kyseinen ohjelma ei ole vielä edes valmis!

Ohjelmahan on valmis sitten kun siitä on yhteensopivaksi testattu ja valmiiksi käännetty paketti alustalle. Avoimen lähdekoodin ohjelmistoissa on tavallista, että kehittäjä puskee uutta versiota ulos ns. ketterän mallin mukaisesti, uutta versiota tiheään tahtiin ja homma elää kokoajan, mutta ne eivät ole valmiita vaan se tuotteistus jätetty sitten käyttöjärjestelmän toimittajalle ja siinä sitten tulee useampiportainen testaus ennen kuin on se on oikeasti valmis.

Sopii kysyä: miksi linux -maailmassa oikein tahallaan tehdään homma hankalaksi ?

Yksi parhaista ratkaisuista voisi olla tämä:

1. Otetaan WINE -lähdekoodi.

2. muokataan siitä sellainen versio, joka ei ole tarkoitettu windows -ohjelmien ajamiseen (kuten alkuperäinen WINE) vaan sellaisten linux -ohjelmien ajamiseen, jotka käyttävät windows APIa, ja windows APIn suurin etuhan on se, että se on Microsoftin erittäin hyvin dokumentoima, ja lisäksi se ei muutu jatkuvasti sellaisella tavalla, joka rikkoisi yhteensopivuuden. Uusia funktioita kyllä tulee, mutta vanhoja ei niiden ensiesittelyn jälkeen koskaan muuteta sellaisella tavalla, että vanhan binääriohjelman yhteensopivuus hajoaisi. Tämä onkin windows APIn suurin etu linuxin erilaisiin ohjelmointirajapintoihin verrattuna, joista eri jakelujen välillä voi olla suuriakin eroja (tässä eri jakelu voi yhtä lailla tarkoittaa fedora vs. debian tai se voi tarkoittaa debian 3.1 vs. uusin debian).

3. kirjoitetaan linux -ohjelmat siten, että ne ovat kyllä natiiveja linuxohjelmia (eli siis ELF, eikä exe) mutta silti käyttävät windows APIa ja kohdassa 2 luotua yhteensopivuuskirjastoa, joka voisi olla käyttöjärjestelmän osa ja nimetty esim. windowsapiforlinux.so

Tällaisen systeemin ansiosta täsmälleen sama binääri toimisi yhtä lailla fedorassa, slackwaressa, ubuntussa, mintissä, knoppixissa jne.

Ja, mikä parasta, kun jokaisesta em. jakelusta ilmestyy uusi versio, niin se ei edellyttäisi sovellusohjelman muuttamista millään tavalla, vaan sama binääri toimisi myös päivitysten jälkeen.

Miksi linux -kehittäjä ehdoin tahdoin haluavat ylläpitää systeemiä, jossa aina kun esim. jakelu päivittyy, niin sovellusohjelmat on pakko muokata uusiksi?

parempi_linux kirjoitti:

Sopii kysyä: miksi linux -maailmassa oikein tahallaan tehdään homma hankalaksi ?

Yksi parhaista ratkaisuista voisi olla tämä:

1. Otetaan WINE -lähdekoodi.

2. muokataan siitä sellainen versio, joka ei ole tarkoitettu windows -ohjelmien ajamiseen (kuten alkuperäinen WINE) vaan sellaisten linux -ohjelmien ajamiseen, jotka käyttävät windows APIa, ja windows APIn suurin etuhan on se, että se on Microsoftin erittäin hyvin dokumentoima, ja lisäksi se ei muutu jatkuvasti sellaisella tavalla, joka rikkoisi yhteensopivuuden. Uusia funktioita kyllä tulee, mutta vanhoja ei niiden ensiesittelyn jälkeen koskaan muuteta sellaisella tavalla, että vanhan binääriohjelman yhteensopivuus hajoaisi. Tämä onkin windows APIn suurin etu linuxin erilaisiin ohjelmointirajapintoihin verrattuna, joista eri jakelujen välillä voi olla suuriakin eroja (tässä eri jakelu voi yhtä lailla tarkoittaa fedora vs. debian tai se voi tarkoittaa debian 3.1 vs. uusin debian).

3. kirjoitetaan linux -ohjelmat siten, että ne ovat kyllä natiiveja linuxohjelmia (eli siis ELF, eikä exe) mutta silti käyttävät windows APIa ja kohdassa 2 luotua yhteensopivuuskirjastoa, joka voisi olla käyttöjärjestelmän osa ja nimetty esim. windowsapiforlinux.so

Tällaisen systeemin ansiosta täsmälleen sama binääri toimisi yhtä lailla fedorassa, slackwaressa, ubuntussa, mintissä, knoppixissa jne.

Ja, mikä parasta, kun jokaisesta em. jakelusta ilmestyy uusi versio, niin se ei edellyttäisi sovellusohjelman muuttamista millään tavalla, vaan sama binääri toimisi myös päivitysten jälkeen.

Miksi linux -kehittäjä ehdoin tahdoin haluavat ylläpitää systeemiä, jossa aina kun esim. jakelu päivittyy, niin sovellusohjelmat on pakko muokata uusiksi?

"Sopii kysyä: miksi linux -maailmassa oikein tahallaan tehdään homma hankalaksi ?"

Tämä ei liity mitenkään Linuxiin. Tämä liittyy Spring pelimoottoriin. Ongelmahan tässä on se, että Spring pelimoottori ei ole vakaa vaan muuttuu kaiken aikaa ja tälle tehdyt pelit vaativat tiettyä versiota pelimoottorista toimiakseen. Debianissa taas hommat pidetään vakaina koko julkaisun ajan, kuten tässä oleva Spring joten Debianille tehdyt Spring pelimoottorin pelit tulisi tähdätä tässä olevalle versiolle.

Vaihtoehtoisesti Spring pelimoottorista pitäisi olla kaikki versiot ladattavissa Debianin paketteina, eli Springin kehittäjät sitten uutta versiota tehdessään kääntäisi Debianille ja testaisi että toimii, tällä ajanhetkellä käytössä olevalla Debianin julkaisulla.

"muokataan siitä sellainen versio, joka ei ole tarkoitettu windows -ohjelmien ajamiseen (kuten alkuperäinen WINE) vaan sellaisten linux -ohjelmien ajamiseen, jotka käyttävät windows APIa, ja windows APIn suurin etuhan on se, että se on Microsoftin erittäin hyvin dokumentoima, ja lisäksi se ei muutu jatkuvasti sellaisella tavalla, joka rikkoisi yhteensopivuuden."

Väärin meni. Windows API on heikosti dokumentoitu ja siksi sitä on takaisinmallinnettu Wineen parikymmentä vuotta eikä vieläkään ole täysin kunnossa. Lisäksi se Windows API muuttuu joka Windows versiossa. Siksi Windowsissakin on niitä yhteensopivuustiloja, eli käyttää sitten vanhempia versioita Windows API:sta.

"Tällaisen systeemin ansiosta täsmälleen sama binääri toimisi yhtä lailla fedorassa, slackwaressa, ubuntussa, mintissä, knoppixissa jne."

Nyt tarkoitat standardointia ja viimeiset 12v on ollut olemassa LSB standardi, että LSB kirjastoja vasten tehdyt binäärit toimivat kaikissa LSB käyttöjärjestelmissä. Se standardi vaan alkaa olla aikansa elänyt kohta kun ei kestä tekniikan perässä, mutta toimii edelleen. Ubuntu 14.04 LTS saattaa irrottautua LSB:stä, viimeistään 16.04 LTS.

Vaihtoehtoisesti voi sitten käyttää tekniikkaa joka on tälläiseen tarkoitettu, kuten Javaa. Javassa on taaksepäinyhteensopivuutta monta julkaisua taaksepäin ja toimii joka paikassa missä on Java.

Mielestäni Springistä oli kyllä binäärit jaossa myös, ja ne lienee LSB binäärit.

"fedorassa, slackwaressa, ubuntussa, mintissä, knoppixissa jne."

Fedora on Red Hat Enterprisen kehitysversio, eli Fedoralla toimii jos toimii ja binääreissä tähdätään tietysti valmista Red Hat Enterprisea, mikä on suunnattu ammattikäyttöön.

Slackware, Mint ja Knoppix ovat yks hailee. Sellaisia harrastusjuttuja.

Helpommalla selvisi kun kääntäisi softan vain Ubuntu LTS:lle, Androidille, iOS:lle, Mac OS:lle, Windows RT/8:lle. Nämä ovat ne mitkä on kuluttajille suunnattu ja joilla pelataan. Ei sitä tarvi kehittäjien säätää kaiken maailman viritysten kanssa.

Tai sitten vaan Java joka toimii kaikissa työpöytä ympäristöissä.


"yhteensopivuuskirjastoa, joka voisi olla käyttöjärjestelmän osa ja nimetty esim. windowsapiforlinux.so"

Sitten säädellään tämän kirjaston yhteensopivuutta muuhun järjestelmään...

parempi_linux kirjoitti:

Sopii kysyä: miksi linux -maailmassa oikein tahallaan tehdään homma hankalaksi ?

Yksi parhaista ratkaisuista voisi olla tämä:

1. Otetaan WINE -lähdekoodi.

2. muokataan siitä sellainen versio, joka ei ole tarkoitettu windows -ohjelmien ajamiseen (kuten alkuperäinen WINE) vaan sellaisten linux -ohjelmien ajamiseen, jotka käyttävät windows APIa, ja windows APIn suurin etuhan on se, että se on Microsoftin erittäin hyvin dokumentoima, ja lisäksi se ei muutu jatkuvasti sellaisella tavalla, joka rikkoisi yhteensopivuuden. Uusia funktioita kyllä tulee, mutta vanhoja ei niiden ensiesittelyn jälkeen koskaan muuteta sellaisella tavalla, että vanhan binääriohjelman yhteensopivuus hajoaisi. Tämä onkin windows APIn suurin etu linuxin erilaisiin ohjelmointirajapintoihin verrattuna, joista eri jakelujen välillä voi olla suuriakin eroja (tässä eri jakelu voi yhtä lailla tarkoittaa fedora vs. debian tai se voi tarkoittaa debian 3.1 vs. uusin debian).

3. kirjoitetaan linux -ohjelmat siten, että ne ovat kyllä natiiveja linuxohjelmia (eli siis ELF, eikä exe) mutta silti käyttävät windows APIa ja kohdassa 2 luotua yhteensopivuuskirjastoa, joka voisi olla käyttöjärjestelmän osa ja nimetty esim. windowsapiforlinux.so

Tällaisen systeemin ansiosta täsmälleen sama binääri toimisi yhtä lailla fedorassa, slackwaressa, ubuntussa, mintissä, knoppixissa jne.

Ja, mikä parasta, kun jokaisesta em. jakelusta ilmestyy uusi versio, niin se ei edellyttäisi sovellusohjelman muuttamista millään tavalla, vaan sama binääri toimisi myös päivitysten jälkeen.

Miksi linux -kehittäjä ehdoin tahdoin haluavat ylläpitää systeemiä, jossa aina kun esim. jakelu päivittyy, niin sovellusohjelmat on pakko muokata uusiksi?

"Miksi linux -kehittäjä ehdoin tahdoin haluavat ylläpitää systeemiä, jossa aina kun esim. jakelu päivittyy, niin sovellusohjelmat on pakko muokata uusiksi?"

Kaikkien käyttöjärjestelmien omat vakiosovellusohjelmat muokataan uusiksi uuteen käyttöjärjestelmäjulkaisuun. Kolmannen osapuolen ohjelmia voi myös joutua päivittämään uusia käyttöjärjestelmäjulkaisuja varten. Tämä ei liity mitenkään Linuxiin.

Katso nyt vaikka Internet Exploreria Windowsissa. On todellakin jouduttu muokkaamaan uudelle Windowsille ja ei sitten käy vanhaan Windowsiin uudempi versio eikä päin vastoin.

Mielestäni Spring pelimoottoria käyttävien pelien tulisi integroida pelimoottori siihen pelin asennuspakettiin ja testata tämän asennus Debianille mikäli haluavat jotain muuta versiota kuin mikä käyttöjärjestelmässä on valmiina. Vaihtoehtoisesti Debianille tehtävien Spring pelimoottorin pelien pitäisi käyttää sitä versiota mikä Debianissa on valmiina.

Yrität nyt jotenkin väkisin vääntää tätä asiaa jotenkin Linuxin syyksi jos joku muu on mokaillut.

m-kar kirjoitti:

"Mikäli tarvitsen ohjelmasta versiota 95.0 ja pakettivarastossa uusin on 88.0, niin mistä lataat?"

Vähän kiinnostaa tietää tarkemmin, että mikä ohjelma mahtaa olla kyseessä? Ja mikä toiminto on se tarve? Todennäköisesti teet jotain väärin mutta en tiedä vielä mitä.

Normaalisti käytetään niitä ohjelmia jotka on käyttöjärjestelmässä valmiina koska ne on parhaiten testattu ja helpointa ylläpitää. Jos toiminto on sellainen joka ei ole käyttöjärjestelmässä valmiina niin sitten normaalisti ostetaan/ladataan asennuspaketti ohjelmiston valmistajalta, ja käyttöjärjestelmä on sitten alusta tälläiselle lisäpalikalle.

Jos sitten on kyse jostain avoimen lähdekoodin jutusta jossa käyttöjärjestelmässä on versio 88 ja kehittäjältä löytyy versio 95 pelkkänä lähdekoodina, niin sittenhän tilanne on se, että kyseinen ohjelma ei ole vielä edes valmis!

Ohjelmahan on valmis sitten kun siitä on yhteensopivaksi testattu ja valmiiksi käännetty paketti alustalle. Avoimen lähdekoodin ohjelmistoissa on tavallista, että kehittäjä puskee uutta versiota ulos ns. ketterän mallin mukaisesti, uutta versiota tiheään tahtiin ja homma elää kokoajan, mutta ne eivät ole valmiita vaan se tuotteistus jätetty sitten käyttöjärjestelmän toimittajalle ja siinä sitten tulee useampiportainen testaus ennen kuin on se on oikeasti valmis.

en tajua miks rupeet jankkaamaan. Vastaa siihen mitä kysytään.

Huono vastaus tämäkin, mutta lue alta.

https://fedoraproject.org/wiki/How_to_create_an_RPM_package?rd=PackageMaintainers/CreatingPackageHowTo

Pitää paketoida siksi että paketti on helppo poistaa ja checkinstall tekee paketoinnin se helpoksi. "Oikeitten" pakettien teko taas on hieman monimutkaisempaa.
https://wiki.debian.org/IntroDebianPackaging

ADBhpe kirjoitti:

Pitää paketoida siksi että paketti on helppo poistaa ja checkinstall tekee paketoinnin se helpoksi. "Oikeitten" pakettien teko taas on hieman monimutkaisempaa.
https://wiki.debian.org/IntroDebianPackaging

oikees olet (taitaa olla paketointi tarpeen ainut syy)
muuten homma hoituu (molempiin suuntiin asennus / poisto)
manuaalisesti ?
ite käännetty ohjelma / versio kun ei kuitenkaan huolehdi riippuvuuksistta ?