-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi yall I'd like to discuss the fact that the kopete package is called "kdenetwork3-InstantMessaging". After doing some research (and with some help), I know that the decision to name that package this way comes from SUSE (and not from the KDE team). I think it's not a good idea to name kopete that way, although the name isn't the issue, but the version number. In fact, it's e.g. kdenetwork3-InstantMessaging-3.5.0, but in reality it's some kopete version (e.g. 0.11.x) This raises a number of issues, where the most important is: now there's going to be a kopete 0.12.0 very soon... how are we supposed to name/number the package ? - - we can't name it kdenetwork3-InstantMessaging-3.5.1, because when KDE 3.5.1 will be released (possibly with a different kopete version but, most importantly, built against another version of kdelibs3) it will collide - - we can't name it kopete either (with a Conflicts:kdenetwork3-InstantMessaging) because end users won't see that as an upgrade of kdenetwork3-InstantMessaging - - we /could/ use the release to provide an upgrade, but that's a) misusing the release tag for what is actually a different version number b) a pain to maintain, because maybe SUSE releases an update kdenetwork3-InstantMessaging (with kopete 0.11.x) and then we'd have to re-package it with a higher release number than SUSE c) just an evil workaround and trickery whereas the issue should be solved by giving the package its correct name in the first place Could someone from SUSE please provide some feedback on this ? Stephan ? AJ ? Would it be possible to rename kdenetwork3-InstantMessaging-3.5.0 to kopete-0.11.x ? To me, it really doesn't make any sense to call it "kdenetwork3-InstantMessaging", kopete is not even tightly bound to a specific KDE release, it just creates issues for community packagers who want to provide packages of the latest kopete version. thanks 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) iD8DBQFDpdLer3NMWliFcXcRAnAFAJ4g4vsjTgMerV1Uf4gglUPpxuSZ+gCfQJ/4 IYoI5gmgEpeR07QQY5W6m+8= =FOsv -----END PGP SIGNATURE-----
On Sun, Dec 18, 2005 at 10:21:34PM +0100, Pascal Bleser wrote:
- - we can't name it kopete either (with a Conflicts:kdenetwork3-InstantMessaging) because end users won't see that as an upgrade of kdenetwork3-InstantMessaging
And why can't you communicate this to end users?
Would it be possible to rename kdenetwork3-InstantMessaging-3.5.0 to kopete-0.11.x ? To me, it really doesn't make any sense to call it "kdenetwork3-InstantMessaging", kopete is not even tightly bound to a specific KDE release, it just creates issues for community packagers who
Huh? Kopete is part of the official KDE release. If you wanted to change this this would result in renaming almost all KDE packages to the names of their individual applications and listing _all_ the individual version numbers of the single applications in the KDE spec files. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Schiele wrote:
On Sun, Dec 18, 2005 at 10:21:34PM +0100, Pascal Bleser wrote:
- - we can't name it kopete either (with a Conflicts:kdenetwork3-InstantMessaging) because end users won't see that as an upgrade of kdenetwork3-InstantMessaging
And why can't you communicate this to end users?
Please point me to the all-suse-users mailing list ;)
Would it be possible to rename kdenetwork3-InstantMessaging-3.5.0 to kopete-0.11.x ? To me, it really doesn't make any sense to call it "kdenetwork3-InstantMessaging", kopete is not even tightly bound to a specific KDE release, it just creates issues for community packagers who
Huh? Kopete is part of the official KDE release. If you wanted to change this this would result in renaming almost all KDE packages to the names of their individual applications and listing _all_ the individual version numbers of the single applications in the KDE spec files.
Not exactly. Kopete is part of the official KDE release in the sense that when KDE is released, it includes the latest stable version of kopete. But kopete has a versioning scheme of its own, follows its own releases, _independently_ of KDE releases. 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. 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) iD8DBQFDpd2zr3NMWliFcXcRAmF/AJ0dwNpRD47ec84d9jxoNhzP6gaRHQCeNwUf Xv+N9WgiNKI986AcnmJP0D8= =+GhO -----END PGP SIGNATURE-----
On Sun, Dec 18, 2005 at 11:07:47PM +0100, Pascal Bleser wrote:
Robert Schiele wrote:
And why can't you communicate this to end users?
Please point me to the all-suse-users mailing list ;)
You don't need this. You could add this information to the place where you announce your packages thus if someone reads this list he will find the information that this is intended as an upgrade to the corresponding SUSE package.
Not exactly. Kopete is part of the official KDE release in the sense that when KDE is released, it includes the latest stable version of kopete. But kopete has a versioning scheme of its own, follows its own releases, _independently_ of KDE releases.
e.g. now kopete 0.12.0 is going to be released, but not KDE 3.5.1 at the same time
As it is with most KDE applications that ship with official KDE releases.
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.
I understand your point but your proposed scheme will result in more work for the KDE packagers. And some users might be confused by the fact that they can no longer easily compare whether a specific package is older, newer, or of the same age than the KDE release they have installed. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
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.
Cheers, -- Damian Mihai Liviu Mobile: +40 741 226993; Fax: +1 347-632-4117 Phone : +1 360-526-6441; +1 347-632-4117; +44 0870-3403339 URL: http://liviudm.blogspot.com
-----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-----
On Mon, Dec 19, 2005 at 10:08:01AM +0100, Pascal Bleser wrote:
-----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.
Then add it to the version tag, like 3.5.0.0.12.0. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
participants (3)
-
Liviu Damian -
Pascal Bleser -
Robert Schiele