Hello Pascal,
El Miércoles, 23 de Noviembre de 2005 17:44, Pascal Bleser escribió:
Guillermo Ballester Valor wrote:
Hello,
Hola Guillermo
I've build new RPM packages for amsn, cvs version. They are called 'amsn_cvs' and have some nice and new features with respect the relased 'amsn 0.94'. Note that it is a development version. To install 'amsn_cvs' RPMs you need uninstall 'amsn' because of some conflicts.
If both packages conflict anyway, why do you call it "amsn_cvs" and not just "amsn" ? I agree with pascal. Since the cvs package can not be installed in parrallel with the stable amsn, then there is no reason to use a different naming scheme. Normaly you change names when, for example, you build a package that can be installed "in parallel" with an existing one in your system( because you do not want or just can not upgrate it ). That can be the case of gcc
Hi: El Miércoles, 23 de Noviembre de 2005 18:50, Guillermo Ballester Valor escribió: packages, for instance: then you build the second gcc vesion with a different name and install prefix, in order to install in parallel, and call this package gcc410(-%{version}). cheers saludos jorge
Because one is considered something as 'stable' and the other is 'in development'.
The scheme you proposed is the first I intended. Then I was no sure about to release a cvs version with the same name that the normal release. Some people doesn't like to have potential unstable packages.
In amsn source (and in the initial window), it is also named as amsn 0.95 20051107. That is the reason of '0.95'.
I also have a similar problem with gcc-4.1 compiler. I've backported the compiler in 10.1 to 9.3 and 10.0, with suffix '_41' as complementary to factory gcc compiler. The name-version in suse specs is 'gcc-4.1.0_20051104', mine is 'gcc_41-4.1.0_20051104' . Version could be 4.0_20051104 so it will upgrade when released gcc-4.1.0, but the used snapshot is in 4.1 branch. Any sugestion about how to name it?
IMHO the best name/version scheme would be amsn-0.94_20051123-1...
That way it would supersede amsn-0.94 and yet, when a new release comes out (either 0.94.1 or 0.95), the release version will supersede the CVS snapshot again.
amsn-0.94 amsn-0.94_20051123 => upgrade amsn-0.94_20051205 => upgrade amsn-0.94.1 => upgrade or amsn-0.95 => upgrade as well
It's a similar trick than how to handle "rc" (release candidate), "alpha" or "beta" versions, where you'd use a _0.1 (beta1), _0.2 (beta2) suffix: amsn-0.95_0.1 => 0.95 beta1 amsn-0.95_0.2 => 0.95 beta2 amsn-0.95_1.0 => 0.95 release
Because if you use "rc1" or "beta1" in the version tag, it won't upgrade properly: amsn-0.95beta1 amsn-0.95beta2 => will upgrade, ok amsn-0.95 ======> won't upgrade (!)
On a sidenote, could you also build and include amsn's systray plugin ? I've seen 2 or 3 people asking for amsn packages that include that. Would be nice, especially as an addon RPM (e.g. amsn-systray) ;) (and some work as well, the amsn source code is an awful mess)
There is a c compiled libtray.so in 'util/linux/traydock' directory. Do you mean that or other separate plugin?
(and maybe we should take this thread to the opensuse-packaging list, that's why I'm cross-posting ;))
Of course ;)
Cheers,
Guillermo