YaST tells me that the version kdebase3 I have on my system is: 3.4.3-2 and that in a particular install source is: 3.4.2-26 Here 3.4.2 or 3.4.3 I understand, since I see that under the "About KDE" menu of all KDE apps. What is the significance of the 2 or 26? Thanks.
On Thursday 27 October 2005 01:43 pm, Shriramana Sharma wrote:
YaST tells me that the version kdebase3 I have on my system is:
3.4.3-2
and that in a particular install source is:
3.4.2-26
Here 3.4.2 or 3.4.3 I understand, since I see that under the "About KDE" menu of all KDE apps. What is the significance of the 2 or 26?
Thanks. ========
Those are the "build" numbers.
On Friday 28 October 2005 12:21, Shriramana Sharma wrote:
Friday 28 Oct 2005 00:47 samaye BandiPat alekhiit:
Those are the "build" numbers.
Thank you all, but can I assume that a later build is "better" than an earlier build?
Shriramana.
You can assume that it was intended to be better, at least.
On Friday 28 October 2005 08:35 am, Fergus Wilde wrote:
On Friday 28 October 2005 12:21, Shriramana Sharma wrote:
Friday 28 Oct 2005 00:47 samaye BandiPat alekhiit:
Those are the "build" numbers.
Thank you all, but can I assume that a later build is "better" than an earlier build?
Shriramana.
You can assume that it was intended to be better, at least. =======
Good one, Fergus! :o)
Friday 28 Oct 2005 21:46 samaye BandiPat alekhiit:
Thank you all, but can I assume that a later build is "better" than an earlier build?
You can assume that it was intended to be better, at least.
Any hints on how a packager can try to make a package "better"? Just trying to fathom the inner workings of packaging. I'm sure there will be experienced people here who can speak on it...
Shriramana Sharma [Fri, 28 Oct 2005 23:05:57 +0530]:
Any hints on how a packager can try to make a package "better"?
This number is increased any time the package is (re)built. This can happen for two reasons: 1) package this package depends on changes (so it's rebuilt) 2) the package itself changes. An example for the first case is when a changed gcc package is checked into the build system. This triggers the rebuild of nearly the complete distribution. Examples for the second case are: - fixes for bugs (normal and/or security) - changes in the packaging (i.e. which files go into which sub package) - split into sub packages (not done for released distributions) - changing the way a package is built, i.e changes to the .spec file of a package I hope this helps a bit. BTW, I'd suggest to ask such question on the opensuse mailing list, as it's related to the development of the distribution. Philipp (apology for the overlong sig folks, but it was so perfectly matching for this list :) -- Philipp Thomas work: pth at suse dot de SUSE LINUX Products GmbH, Maxfeldstr.5, 90409 Nuremberg, Germany The daring might even venture to say it's... human nature. (Yes yes, I know there are [mailing list] subscribers whose human status is doubtful, but I'm feeling generous today. :-) Stan Shebs on the gcc ml
participants (4)
-
BandiPat
-
Fergus Wilde
-
Philipp Thomas
-
Shriramana Sharma