-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Liviu Damian wrote:
On Monday 19 December 2005 00:07, Pascal Bleser wrote:
e.g. now kopete 0.12.0 is going to be released, but not KDE 3.5.1 at the same time
In the mean time, I'd like to package kopete 0.12.0 for KDE 3.4.2 (SUSE 10.0) and below, if possible. That's my point in this mail. Just an idea: kdenetwork3-InstantMessaging-%{_kdever}-%{version}. %{release}. Of course this will result in a long version naming but it will be easier to find what's the real kopete version.
(sorry btw, it's "kdenetwork3-InstantMessenger" not "kdenetwork3-InstantMessaging") That doesn't work either, you cannot abuse the "release" tag for kopete's version. If you do that, you (as a packager) cannot use the release tag to provide upgrades of your package. e.g. kdenetwork3-InstantMessenger-3.5.0-0.11.9 then kdenetwork3-InstantMessenger-3.5.0-0.12.0 => works, upgrade But then I notice that either a) there's a (packaging-related) bug in my package that I need to fix b) there's some security or bug fix in kopete's SVN, the developers don't make a new release yet but I already want to include that patch c) I want to improve my kopete package e.g. by adding an emoticons theme pack In any of those cases (or other reasons), I must keep the same %{version} but bump up the %{release} number. As I've already misused the %{release} for kopete's real %{version} number, I'm really starting to get into hell's kitchen, because the only way to provide an upgrade to the end users is to release it like this: kdenetwork3-InstantMessenger-3.5.0-0.12.0_1 then kdenetwork3-InstantMessenger-3.5.0-0.12.0_2 And another reason why this idea is problematic is that the kdenetwork3-InstantMessenger package released by SUSE, e.g. in Supplementary, is currently kdenetwork3-InstantMessenger-3.5.0-7 which means that if I want to package kopete 0.12.0, I'd have to name the package... kdenetwork3-InstantMessenger-3.5.0-8_0.12.0_0 Note that although the latter seems ugly but "would work", it's still problematic. Imagine that the SUSE KDE team notices there's some critical security patch to add, and that they release a new kdenetwork3-InstantMessenger-3.5.0 If they do so, they will change the %{release} number. As with SUSE packages the %{release} number is computed automatically by the internal build system, it won't be "8" but maybe "12" or "25": kdenetwork3-InstantMessenger-3.5.0-12 What will happen ? End users will refresh their KDE Supplementary installation source and see that there's a new release, so they will upgrade => hence they will be downgrading kopete 0.12.0 back to 0.11.x. What will I have to do ? Look up the release number used by SUSE, and rebuild my kopete package as kdenetwork3-InstantMessenger-3.5.0-13_0.12.0_0 It is feasible, but a lot of unnecessary work, trickery and dirty hacks, whereas my point is that the package %{name} and %{version} should be "fixed" in the first place, by calling the package "kopete-0.11.x" instead of "kdenetwork3-InstantMessenger-3.5.0". I hope this clarifies that the issue at hand is not simple and what the problems are that arise from naming the kopete package this way ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpnhwr3NMWliFcXcRAnnfAJ9szzUHoxnFMb0+cLOwrs0pc23hRQCfWLJF FlkboxgJg7ZrRy4IF59xKKU= =sG8C -----END PGP SIGNATURE-----