Mailinglist Archive: opensuse-packaging (89 mails)

< Previous Next >
Re: [opensuse-packaging] kdenetwork3-InstantMessaging vs kopete
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Mon, 19 Dec 2005 10:08:01 +0100
  • Message-id: <43A67871.4000403@xxxxxxxxx>
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:
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
which means that if I want to package kopete 0.12.0, I'd have to name the package...

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":

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

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 ;)

- --
-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
Version: GnuPG v1.4.2 (GNU/Linux)


< Previous Next >
Follow Ups