RPM csomagnevek
Kiss Gabor
Sajnos nem értek annyira az RPM/yum vonalhoz, mint kellene. Elakadtam.
Adott egy csomag. Volt benne egy hiba. Elővettem az rpmbuild programot
és megpatcheltem. A régi release 1 volt, az új e_2 lett.
Betettem a repóba.
Ennyit lát belőle a target host:
# yum list --showduplicates perl-XML-Validator-Schema
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
Installed Packages
perl-XML-Validator-Schema.noarch 1.10-1.el6 @Repo1
Available Packages
perl-XML-Validator-Schema.noarch 1.10-e_2.el6 Repo1
perl-XML-Validator-Schema.noarch 1.10-1.el6 Repo2
#
A
https://www.thegeekdiary.com/understanding-rpm-versions-and-naming-schemes/
oldal szerint az "e_2" frissebbnek számít, mint az "1".
És ennek dacára mégsem hajlandó a nyavalyás yum frissíteni 1.10-e_2-re.
Nem tudom hogy igaz-e amit olvastam a fenti linken, illetve hogy miként
kell ezt debugolni. Debianban az apt-cache policy segítőkészebb.
A target egy CentOS 6, a yum verziója 3.2.29-81.el6.centos.0.1.
Szeretném elkerülni, hogy ötletszerűen gyártsak egy tucat másik csomagot
mindenféle nevekkel, és kikísérletezem, hogy melyiket hiszi frissebbnek
a yum.
"Please help" (Lilu Az ötödik elemben)
kissg
_________________________________________________
linux lista - li...@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux
Kiss Gabor
On 3/4/21 1:16 PM, Kiss Gabor wrote:
> A
> https://www.thegeekdiary.com/understanding-rpm-versions-and-naming-schemes/
> oldal szerint az "e_2" frissebbnek számít, mint az "1".
> Nem tudom hogy igaz-e amit olvastam a fenti linken,
Az anyja szömit! És nem igaz.
https://ftp.lip6.fr/pub/linux/rpm/api/4.4.2.2/rpmvercmp_8c-source.html
00076 /* numeric segments are always newer than alpha segments */
Akkor viszont találhatom ki, mi lenne az a release string, ami übereli
az "1"-t, és a hivatalos csomagolók nem fogják használni soha.
20210304.1? :-(
kissg
--
Use the source, Luke.
Varadi Gabor
>
> On 3/4/21 1:16 PM, Kiss Gabor wrote:
>
>> A
>> https://www.thegeekdiary.com/understanding-rpm-versions-and-naming-schemes/
>>
>> oldal szerint az "e_2" frissebbnek számít, mint az "1".
>
>> Nem tudom hogy igaz-e amit olvastam a fenti linken,
>
> Az anyja szömit! És nem igaz.
>
> https://ftp.lip6.fr/pub/linux/rpm/api/4.4.2.2/rpmvercmp_8c-source.html
>
> 00076 /* numeric segments are always newer than alpha segments */
>
> Akkor viszont találhatom ki, mi lenne az a release string, ami übereli
> az "1"-t, és a hivatalos csomagolók nem fogják használni soha.
> 20210304.1? :-(
>
> kissg
1.10-1.el6
helyett
1.10-1-mypkg.el6
--
[Varadi Gabor]
Hegedüs Ervin
On Thu, Mar 04, 2021 at 02:23:38PM +0100, Kiss Gabor wrote:
>
> On 3/4/21 1:16 PM, Kiss Gabor wrote:
>
> > A
> > https://www.thegeekdiary.com/understanding-rpm-versions-and-naming-schemes/
> > oldal szerint az "e_2" frissebbnek számít, mint az "1".
>
> > Nem tudom hogy igaz-e amit olvastam a fenti linken,
>
> Az anyja szömit! És nem igaz.
>
> https://ftp.lip6.fr/pub/linux/rpm/api/4.4.2.2/rpmvercmp_8c-source.html
>
> 00076 /* numeric segments are always newer than alpha segments */
>
> Akkor viszont találhatom ki, mi lenne az a release string, ami übereli
> az "1"-t, és a hivatalos csomagolók nem fogják használni soha.
> 20210304.1? :-(
bár én sem vagyok nagy yum/rpm/... szagértő, de én így csinálnám.
Nemrég csináltam saját Debian/Ubuntu repository-t bizonyos
csomagoknak, és ott ezt követtem.
Pl.:
3.0.3-1+deb10u2 - ez a Debian official repoban levő csomag
3.0.5pre-1+0~20210114.01+debian10~1.310cbf - ez meg a saját.
a.
Kiss Gabor
On 3/4/21 3:11 PM, Varadi Gabor wrote:
> 1.10-1.el6
>
> helyett
>
> 1.10-1-mypkg.el6
Amit viszont felülcsapna a következő gyári, az 1.10-2.el6.
Legalábbis elméletben. Ha lenne még frissítés a CentOS 6-hoz.
De már úgyis csak elméleti megbeszélést folytatunk, mert
1.10-2021_5 lett végül.
kissg
Kiss Gabor
On 3/4/21 5:29 PM, Hegedüs Ervin wrote:
> Nemrég csináltam saját Debian/Ubuntu repository-t bizonyos
> csomagoknak, és ott ezt követtem.
>
> Pl.:
>
> 3.0.3-1+deb10u2 - ez a Debian official repoban levő csomag
>
> 3.0.5pre-1+0~20210114.01+debian10~1.310cbf - ez meg a saját.
Itt már a verziószám is nagyobb eleve.
Nem hasonlít az én esetemhez. Nem nagyon.
De hasonló gondokat látok felmerülni.
Mert amikor kijön a gyári 3.0.5-1, akkor
nem fog érvényesülni a tiéddel szemben. 5pre üti az 5-öt.
Ha így tervezted, akkor jó. Ha nem, akkor figyelned kell.
g
Hegedüs Ervin
On Fri, Mar 05, 2021 at 08:03:14AM +0100, Kiss Gabor wrote:
>
> On 3/4/21 5:29 PM, Hegedüs Ervin wrote:
>
> > Nemrég csináltam saját Debian/Ubuntu repository-t bizonyos
> > csomagoknak, és ott ezt követtem.
> >
> > Pl.:
> >
> > 3.0.3-1+deb10u2 - ez a Debian official repoban levő csomag
> >
> > 3.0.5pre-1+0~20210114.01+debian10~1.310cbf - ez meg a saját.
>
> Itt már a verziószám is nagyobb eleve.
egyrészt igen, mondjuk itt a cél is az volt, hogy a forrás master
ágba már becomittolt módosítások bent legyenek a csomagban -
viszont a forrásból még nincs új verzió.
> Nem hasonlít az én esetemhez. Nem nagyon.
közben rájöttem, hogy egyáltalán nem :).
> De hasonló gondokat látok felmerülni.
> Mert amikor kijön a gyári 3.0.5-1, akkor
> nem fog érvényesülni a tiéddel szemben. 5pre üti az 5-öt.
> Ha így tervezted, akkor jó. Ha nem, akkor figyelned kell.
Valszeg nem fog kijönni - mivel Debianról van szó, pont az a
probléma, hogy ha ki is jön, az most a SID-be kerül be max, majd
a testing-be, ami majd valamikor stable lesz. Ezek viszont kvázi
backport csomagok.
Másrészt ugye ahogy írtad, Debian esetében ott az apt policy, és
én igazából ezzel oldom meg a problémát.
Szal elnéztem, csak már nem akartam külön emiatt írni :P
a.
wf...@niif.hu
> On Fri, Mar 05, 2021 at 08:03:14AM +0100, Kiss Gabor wrote:
>
>> Mert amikor kijön a gyári 3.0.5-1, akkor nem fog érvényesülni a
>> tiéddel szemben. 5pre üti az 5-öt.
>
> Valszeg nem fog kijönni - mivel Debianról van szó, pont az a
> probléma, hogy ha ki is jön, az most a SID-be kerül be max, majd
> a testing-be, ami majd valamikor stable lesz. Ezek viszont kvázi
> backport csomagok.
Ha kijön a következő stable Debian 1.0.5-tel, amikor neked még
valamelyik 1.0.5pre változat van telepítve, akkor nem az fog történni,
aminek kellene. Pont erre van kitalálva a ~ karakter a Debian
verizójelölésekben: az a semminél kisebb. Így például:
1.0.4 < 1.0.4.99 < 1.0.5~alpha3 < 1.0.5~beta1 < 1.0.5~rc2 < 1.0.5
Backportok verziózására is hasznos, de íme a szokásos watch file
fordulat az upstream verzió "jól sorrendezővé" alakítására:
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/
--
Feri
Hegedüs Ervin
On Fri, Mar 05, 2021 at 06:56:04PM +0100, wf...@niif.hu wrote:
> Hegedüs Ervin <air...@arxnet.hu> writes:
>
> > On Fri, Mar 05, 2021 at 08:03:14AM +0100, Kiss Gabor wrote:
> >
> >> Mert amikor kijön a gyári 3.0.5-1, akkor nem fog érvényesülni a
> >> tiéddel szemben. 5pre üti az 5-öt.
> >
> > Valszeg nem fog kijönni - mivel Debianról van szó, pont az a
> > probléma, hogy ha ki is jön, az most a SID-be kerül be max, majd
> > a testing-be, ami majd valamikor stable lesz. Ezek viszont kvázi
> > backport csomagok.
>
> Ha kijön a következő stable Debian 1.0.5-tel, amikor neked még
> valamelyik 1.0.5pre változat van telepítve, akkor nem az fog történni,
> aminek kellene.
valóban, köszi az észrevételt.
Egyébként egy ilyen esetben a verzió felülírja a policy
beállítást is?
(Megj.: esetemben nem nagyon kell attól tartani, hogy egy adott
Debian verzión belül kijön egy újabb upstream verzió... :))
> Pont erre van kitalálva a ~ karakter a Debian
> verizójelölésekben: az a semminél kisebb. Így például:
>
> 1.0.4 < 1.0.4.99 < 1.0.5~alpha3 < 1.0.5~beta1 < 1.0.5~rc2 < 1.0.5
ez az, amit így leírva nem találtam meg - de simán lehet, hogy én
voltam figyelmetlen.
> Backportok verziózására is hasznos, de íme a szokásos watch file
> fordulat az upstream verzió "jól sorrendezővé" alakítására:
>
> uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/
Nos, azt hiszem akkor elkezdem az újrabuildelést :).
Köszi,
a.
wf...@niif.hu
> On Fri, Mar 05, 2021 at 06:56:04PM +0100, wf...@niif.hu wrote:
>
>> Ha kijön a következő stable Debian 1.0.5-tel, amikor neked még
>> valamelyik 1.0.5pre változat van telepítve, akkor nem az fog
>> történni, aminek kellene.
>
> valóban, köszi az észrevételt.
>
> Egyébként egy ilyen esetben a verzió felülírja a policy
> beállítást is?
Szia Ervin!
Nem egészen értem, mire gondolsz. Az APT minden elérhető verzióhoz
rendel egy prioritást, majd annak alapján dolgozik tovább. A verziók
azt döntik el, hogy mi számít upgrade-nek vagy downgrade-nek, ezekre
ugyanis eltérő szabályok vonatkoznak.
>> Pont erre van kitalálva a ~ karakter a Debian
>> verizójelölésekben: az a semminél kisebb. Így például:
>>
>> 1.0.4 < 1.0.4.99 < 1.0.5~alpha3 < 1.0.5~beta1 < 1.0.5~rc2 < 1.0.5
>
> ez az, amit így leírva nem találtam meg - de simán lehet, hogy én
> voltam figyelmetlen.
Lásd man deb-version, de a forrás természetesen a Debian Policy:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
--
Üdv: Feri
Hegedüs Ervin
On Sun, Mar 07, 2021 at 08:17:26AM +0100, wf...@niif.hu wrote:
> Hegedüs Ervin <air...@arxnet.hu> writes:
> > On Fri, Mar 05, 2021 at 06:56:04PM +0100, wf...@niif.hu wrote:
> >
> >> Ha kijön a következő stable Debian 1.0.5-tel, amikor neked még
> >> valamelyik 1.0.5pre változat van telepítve, akkor nem az fog
> >> történni, aminek kellene.
> >
> > Egyébként egy ilyen esetben a verzió felülírja a policy
> > beállítást is?
>
> Nem egészen értem, mire gondolsz. Az APT minden elérhető verzióhoz
> rendel egy prioritást, majd annak alapján dolgozik tovább. A verziók
> azt döntik el, hogy mi számít upgrade-nek vagy downgrade-nek, ezekre
> ugyanis eltérő szabályok vonatkoznak.
pl. ha egy csomagnak egy adott repository-ban magasabb prioritást
adok, és ha egy alacsonyabb prioritású repository-ban megjelenik
egy frisebb verzió, akkor fog-e frissülni a csomag?
> >> 1.0.4 < 1.0.4.99 < 1.0.5~alpha3 < 1.0.5~beta1 < 1.0.5~rc2 < 1.0.5
> >
> > ez az, amit így leírva nem találtam meg - de simán lehet, hogy én
> > voltam figyelmetlen.
>
> Lásd man deb-version, de a forrás természetesen a Debian Policy:
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
ezt megtaláltam, lehet, hogy értelmezni is kellett volna :). Az
általad írt példa elég jól magyaráz - lehet, hogy ezt még
elviselné az a doksi :).
Köszi,
a.
Kiss Gabor
On 3/7/21 9:31 AM, Hegedüs Ervin wrote:
> pl. ha egy csomagnak egy adott repository-ban magasabb prioritást
> adok, és ha egy alacsonyabb prioritású repository-ban megjelenik
> egy frisebb verzió, akkor fog-e frissülni a csomag?
Ha jól emlékszem, ez a prioritás konkrét értékétől is függ.
Predesztinált értéktartományok vannak.
Az egyik így viselkedik, a másik úgy.
kissg
Hegedüs Ervin
On Sun, Mar 07, 2021 at 04:45:08PM +0100, Kiss Gabor wrote:
> On 3/7/21 9:31 AM, Hegedüs Ervin wrote:
> > pl. ha egy csomagnak egy adott repository-ban magasabb prioritást
> > adok, és ha egy alacsonyabb prioritású repository-ban megjelenik
> > egy frisebb verzió, akkor fog-e frissülni a csomag?
>
> Ha jól emlékszem, ez a prioritás konkrét értékétől is függ.
> Predesztinált értéktartományok vannak.
> Az egyik így viselkedik, a másik úgy.
erre gondolsz?
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#listofnotablepinpinningtechnique
(csak az archívum kedvéért :))
a.
Kiss Gabor
On 3/6/21 2:12 PM, Zs wrote:
> Debian alatt ilyen esetben biztosra megyek: HOLD-ra teszem
> a csomagot oszt frissítsd ha tudod.
> Ráadásul mezei frissítésnél szól is, hogy lenne mit frissíteni,
> de nem frissít, mert HOLD-on van a csomag.
>
> Csacska kérdés: az rpm alapú disztrók esetén hasonló
> megoldás nincs?
Ki tudja? Version lock viszont van. (V.ö. apt pinning)
kissg