Multiple YOU patches with _seemingly_ outdated versions...
Hi List! I made a short PERL script, for doing some statistics-analysis on all of the new and obsolete patches available via YOU. But there are several packages, where I can't find out, what is behind, and why I see sometimes seemingly outdated packages. One example xine-ui and xine-lib, where actually both of them were build from xine-lib-xxx.nosrc.rpm, but as the vulnerability was discovered, from TWO different versions: Buildtime: 2004-04-26 16:18:03 Package: xine-ui-0.99.rc3a-106.3.i586.rpm Source: (xine-lib-0.99.rc3a-106.3.nosrc.rpm) Buildtime: 2004-11-16 13:55:32 Package: xine-lib-0.99.rc3a-106.15.i586.rpm Source: (xine-lib-0.99.rc3a-106.15.nosrc.rpm) My question would be (even, that I realized, that there is nothing wrong!), that how is this possible, that after the second patch got available via YOU, the xine-ui-0.99.rc3a-106.15.i586.rpm was not build again from the updated source? Another, more theoretical question would be, that in case one decides to build e.g. the first package from the _newer_ source, would one get the same as the prior variant xine-ui, only with a tiny change exclusively in the version-numbers? (While checking the output of my program, in the case of some arts, dhcp, kdelibs3, subversion, and XFree86 packages the situation is very similar: few updated rpms coming from updated sources, but their 'sisters' got no update...) I'm not so familiar with deeper rpm-related themes, so I would be really hapy to get a correct explanation, more or less on the user-level:) Thanks a lot, Pelibali
On Tue, Jan 18, 2005 at 11:52:19PM +0100, pelibali wrote:
Hi List!
I made a short PERL script, for doing some statistics-analysis on all of the new and obsolete patches available via YOU. But there are several packages, where I can't find out, what is behind, and why I see sometimes seemingly outdated packages. One example xine-ui and xine-lib, where actually both of them were build from xine-lib-xxx.nosrc.rpm, but as the vulnerability was discovered, from TWO different versions:
Buildtime: 2004-04-26 16:18:03 Package: xine-ui-0.99.rc3a-106.3.i586.rpm Source: (xine-lib-0.99.rc3a-106.3.nosrc.rpm)
Buildtime: 2004-11-16 13:55:32 Package: xine-lib-0.99.rc3a-106.15.i586.rpm Source: (xine-lib-0.99.rc3a-106.15.nosrc.rpm)
My question would be (even, that I realized, that there is nothing wrong!), that how is this possible, that after the second patch got available via YOU, the xine-ui-0.99.rc3a-106.15.i586.rpm was not build again from the updated source? Another, more theoretical question would be, that in case one decides to build e.g. the first package from the _newer_ source, would one get the same as the prior variant xine-ui, only with a tiny change exclusively in the version-numbers? (While checking the output of my program, in the case of some arts, dhcp, kdelibs3, subversion, and XFree86 packages the situation is very similar: few updated rpms coming from updated sources, but their 'sisters' got no update...)
I'm not so familiar with deeper rpm-related themes, so I would be really hapy to get a correct explanation, more or less on the user-level:)
We relase binary packagesets, not all binary packages belonging to one source rpm. So while internally xine-ui is a newer version, only xine-lib was released to the outside. If you think we released the wrong RPM at some times, please do tell. Ciao, Marcus
On Wed, 19 Jan 2005 18:40:17 +0100 Marcus Meissner <.> wrote: ...
We relase binary packagesets, not all binary packages belonging to one source rpm.
So while internally xine-ui is a newer version, only xine-lib was released to the outside.
If you think we released the wrong RPM at some times, please do tell.
Ciao, Marcus
Hi, I'm not sure, that I can explain completely, what I meant in my previous posting to the mailing-list. Let's take another example, the 'subversion' package. There are two groups of updates available for the subversion-related packages: 2004-09-24 17:50:26 RPM1: subversion-1.0.0-73.14.i586.rpm RPM2: subversion-devel-1.0.0-73.14.i586.rpm RPM3: subversion-server-1.0.0-73.14.i586.rpm SRC: (subversion-1.0.0-73.14.src.rpm) 2004-12-17 23:46:55 RPM1: subversion-viewcvs-1.0.0-73.17.i586.rpm SRC: (subversion-1.0.0-73.17.src.rpm) So there was a first round of updates, and also a second one; and these two groups of rpms were build from two different source as well. My question was, that in December 2004, when the updated subversion-viewcvs package appeared via YOU; shouldn't be all of the other subversion-related packages updated again? I mean, that the later source has 1.0.0-73.17, and all of the previously patched rpms were just 1.0.0-73.14 ! Hope, that it's clear now. Actually do you know, where to check in case I would like to know more about the version and release numbers? I would like to know a little more on the nomenclature; and actually find an explanation, how you (and others) make up this numbers. I have e.g. subversion 1.0.0-51 originally, but after a security-flaw when update was needed, I have to change two lines in the code, so should be now 1.0.0-51.2 or just something similar? Is it related somehow also to the different kernel versions as 2.4.x and 2.6.x ? I guess, that with the first update-problem I'm not right; but please explain in brief, and any advice would be appreciated concerning the version-numbers. Thank you again:) Pelibali
On Fri, Jan 21, 2005 at 10:44:03AM +0100, pelibali wrote:
So there was a first round of updates, and also a second one; and these two groups of rpms were build from two different source as well. My question was, that in December 2004, when the updated subversion-viewcvs package appeared via YOU; shouldn't be all of the other subversion-related packages updated again? I mean, that the
Why should all packages be updated again, if only one package was affected by a fix? To waste some extra bandwidth? Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
participants (3)
-
Marcus Meissner -
pelibali -
Robert Schiele