[opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

[opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number really needed?

older
[opensuse-kde] Fwd: [Bug 133614]...

Cristian Morales Vega

17 Apr 2010 17 Apr '10

09:47

The kdelibs4 spec file in KDE:KDE4:Factory:Desktop has: # # define KDE version exactly # sed -ri "s,#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@\",#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@ \\\\\"release $(echo %release | cut -d. -f-1)\\\\\"\"," kdecore/util/kdeversion.h.cmake So every time kdelibs4 is rebuilt: - Even if it has no changes (but the KDE_VERSION_STRING in the header) the package is published for users to download - So every package that depends on kdelibs4 is rebuilt - Most of these packages get a modification because of the KDE_VERSION_STRING in the header (every app with an "About box") and so are also published for users to download We could save build power and bandwidth without the RPM release number in KDE_VERSION_STRING. So, why it is there? I don't see what we gain having "the KDE version defined exactly". -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Show replies by date

Andreas Jaeger

19 Apr 19 Apr

07:58

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

On Saturday 17 April 2010 11:47:29 Cristian Morales Vega wrote:

...

The kdelibs4 spec file in KDE:KDE4:Factory:Desktop has:

# # define KDE version exactly # sed -ri "s,#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@\",#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@ \\\\\"release $(echo %release | cut -d. -f-1)\\\\\"\"," kdecore/util/kdeversion.h.cmake

So every time kdelibs4 is rebuilt: - Even if it has no changes (but the KDE_VERSION_STRING in the header) the package is published for users to download - So every package that depends on kdelibs4 is rebuilt - Most of these packages get a modification because of the KDE_VERSION_STRING in the header (every app with an "About box") and so are also published for users to download

We could save build power and bandwidth without the RPM release number in KDE_VERSION_STRING. So, why it is there? I don't see what we gain having "the KDE version defined exactly".

I agree, let's remove the change... Any volunteers? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Cristian Morales Vega

18:42

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

2010/4/19 Andreas Jaeger :

...

On Saturday 17 April 2010 11:47:29 Cristian Morales Vega wrote:

...
The kdelibs4 spec file in KDE:KDE4:Factory:Desktop has:

# # define KDE version exactly # sed -ri "s,#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@\",#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@ \\\\\"release $(echo %release | cut -d. -f-1)\\\\\"\"," kdecore/util/kdeversion.h.cmake

So every time kdelibs4 is rebuilt: - Even if it has no changes (but the KDE_VERSION_STRING in the header) the package is published for users to download - So every package that depends on kdelibs4 is rebuilt - Most of these packages get a modification because of the KDE_VERSION_STRING in the header (every app with an "About box") and so are also published for users to download

We could save build power and bandwidth without the RPM release number in KDE_VERSION_STRING. So, why it is there? I don't see what we gain having "the KDE version defined exactly".

I agree, let's remove the change... Any volunteers?

SR #38288 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Dirk Müller

21 Apr 21 Apr

08:43

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

On Saturday 17 April 2010, Cristian Morales Vega wrote:

...

So every time kdelibs4 is rebuilt: - Even if it has no changes (but the KDE_VERSION_STRING in the header) the package is published for users to download - So every package that depends on kdelibs4 is rebuilt - Most of these packages get a modification because of the KDE_VERSION_STRING in the header (every app with an "About box") and so are also published for users to download

thats indeed bad. we need to remove the rebuild counter from the version string, so that build-compare does the rest.

...

We could save build power and bandwidth without the RPM release number in KDE_VERSION_STRING. So, why it is there? I don't see what we gain having "the KDE version defined exactly".

it was done for knowing in bugreports which kde version the user actually used (for released products). we could remove the release suffix for factory and KKFD packages, and only keep them in maintenance. that would be another solution. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Cristian Morales Vega

12:13

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

2010/4/21 Dirk Müller :

...

On Saturday 17 April 2010, Cristian Morales Vega wrote:

...
We could save build power and bandwidth without the RPM release number in KDE_VERSION_STRING. So, why it is there? I don't see what we gain having "the KDE version defined exactly".

it was done for knowing in bugreports which kde version the user actually used (for released products).

we could remove the release suffix for factory and KKFD packages, and only keep them in maintenance. that would be another solution.

That's fine with me. If when I arrive home nobody has done it I will create a new SR. There is something like a "_releaseversion" variable in projects config or should I use %_project and a custom list? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Dirk Müller

22 Apr 22 Apr

09:11

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

On Wednesday 21 April 2010, Cristian Morales Vega wrote:

...

If when I arrive home nobody has done it I will create a new SR. There is something like a "_releaseversion" variable in projects config or should I use %_project and a custom list?

for detecting if it is a "maintenance" version of kdelibs4? not really, at least I'm not aware of it. the kernel-source spec files strip away the rebuild counter. I think this would globally solve the issue as well. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Cristian Morales Vega

20:04

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

2010/4/22 Dirk Müller :

...

On Wednesday 21 April 2010, Cristian Morales Vega wrote:

...
If when I arrive home nobody has done it I will create a new SR. There is something like a "_releaseversion" variable in projects config or should I use %_project and a custom list?

for detecting if it is a "maintenance" version of kdelibs4? not really, at least I'm not aware of it.

So the options are: - Remove the sed only for %_project "KDE:KDE4:Factory:Desktop", "KDE:KDE4:STABLE:Desktop" and "KDE:KDE4:UNSTABLE:Desktop" - Add the sed only for %_project "openSUSE:*" and "SUSE:*" (wrong things as "openSUSE:Tools" would match) - Remove the sed if a special variable defined in KDE:* projects in defined (in case the same thing needs to be done for other KDE packages) - ...?

...

the kernel-source spec files strip away the rebuild counter. I think this would globally solve the issue as well.

I didn't found the strip in the kernel-source spec. But removing the rebuild counter we solve the problem when a rebuild is triggered because of a change in a third library. But it could still happen that somebody changes the kdelibs4 spec file without causing any effect in the generated binaries. If you remove the rebuild counter you remove the problem for rebuilds. But to remove the problem for new releases the full release number needs to be removed from KDE_VERSION_STRING. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Cristian Morales Vega

24 Apr 24 Apr

10:12

New subject: [opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number *really* needed?

2010/4/22 Cristian Morales Vega :

...

2010/4/22 Dirk Müller :

...
the kernel-source spec files strip away the rebuild counter. I think this would globally solve the issue as well.

I didn't found the strip in the kernel-source spec. But removing the rebuild counter we solve the problem when a rebuild is triggered because of a change in a third library. But it could still happen that somebody changes the kdelibs4 spec file without causing any effect in the generated binaries. If you remove the rebuild counter you remove the problem for rebuilds. But to remove the problem for new releases the full release number needs to be removed from KDE_VERSION_STRING.

...

From a start the KDE_VERSION_STRING contained the release number **without** the rebuild counter. The only real problem with this is

Since I was thinking this the wrong way, to make it clearer... that it generates differences in other packages that depend on it. If we remove the *full* release number from KDE_VERSION_STRING: - There will be no differences for kdelibs4 itself. If the spec file is changed the package will get rebuilt and published, and that will trigger the rebuild of dependent packages. - Dependent packages will get rebuilt, but what we gain is that they will not be published if there is no need. Right now they are published if the generated binaries depend on the KDE_VERSION_STRING value (at least every app with an About box) So there is no gain in build power (perhaps in "second level" dependencies), only in bandwidth. Without a better way, I created SR #38665 with: if [ '%{_project}' != KDE:KDE4:Factory:Desktop -a \ '%{_project}' != KDE:KDE4:UNSTABLE:Desktop -a \ '%{_project}' != KDE:KDE4:STABLE:Desktop -a \ '%{_project}' != openSUSE:Factory ] ; then sed -ri "s,#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@\",#cmakedefine KDE_VERSION_STRING \"@KDE_VERSION_STRING@ \\\\\"release $(echo %release | cut -d. -f-1)\\\\\"\"," kdecore/util/kdeversion.h.cmake fi -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

5117

Age (days ago)

5124

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Andreas Jaeger
Cristian Morales Vega
Dirk Müller

tags

participants (3)

[opensuse-kde] KDE_VERSION_STRING in kdelibs4, is the release number really needed?