Antonio Larrosa writes:

On 31/05/17 12:26, Jan Engelhardt wrote:

...

On Wednesday 2017-05-31 12:23, Antonio Larrosa wrote:

...

The full list of macros added and simple descriptions is:

%pkg_version_at_least : Arguments are a package/capability name and a version number and returns true if package >= version %pkg_version_at_most : package <= version %pkg_version_equals : package == version %pkg_version_greater_than : package > version %pkg_version_less_than : package < version %pkg_version_not_equals : package != version

So, any opinion/suggestion about these macros?

So much to type. Can't we just have something similar to %requires_ge, _gt, _le, _lt, _eq, _ne?

I thought about that, but it's not actually a "requirement" so %requires_* is not accurate and may clash with other macro names in the future. I also thought about using %pkg_version_ge _gt ... but I thought what I submitted was more readable and you read the code more times than you write it :). I'm open to change the names in that sense though if it's generally accepted that those names are preferred.

And can that be in form %pkg_version gcc <= 7.0 or there are limits on rpm side? -- Nikola -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 31/05/17 12:37, Nikola Pajkovsky wrote:

Antonio Larrosa writes:

...

On 31/05/17 12:26, Jan Engelhardt wrote:

...

On Wednesday 2017-05-31 12:23, Antonio Larrosa wrote:

...

The full list of macros added and simple descriptions is:

%pkg_version_at_least : Arguments are a package/capability name and a version number and returns true if package >= version %pkg_version_at_most : package <= version %pkg_version_equals : package == version %pkg_version_greater_than : package > version %pkg_version_less_than : package < version %pkg_version_not_equals : package != version

So, any opinion/suggestion about these macros?

So much to type. Can't we just have something similar to %requires_ge, _gt, _le, _lt, _eq, _ne?

I thought about that, but it's not actually a "requirement" so %requires_* is not accurate and may clash with other macro names in the future. I also thought about using %pkg_version_ge _gt ... but I thought what I submitted was more readable and you read the code more times than you write it :). I'm open to change the names in that sense though if it's generally accepted that those names are preferred.

And can that be in form

%pkg_version gcc <= 7.0

or there are limits on rpm side?

Hmm, I think that's a very good idea. Just note pkg_version is the macro that returns the package version, so I'll call it %pkg_version_test if that's ok for you. That could very well replace the %pkg_version_at_least/ %pkg_version_at_most/... "high-level" macros with something probably even more readable and equally short. -- Antonio Larrosa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2017.05.31 18:01, Antonio Larrosa rašė:

Just wondering... let's do a small poll. How would you call ... 1) The macro that has one argument (package name) and returns its version number? a) pkg_version b) pkg_version_number c) package_version d) pkg_ver other?

2) The macro that has 3 arguments (package_name, operator, version number) and tests whether the condition is true or not? a) pkg_version_test b) pkg_version_check c) pkg_version d) is_pkg_version e) test_pkg_version other?

Note that 1.a and 2.c can't be chosen at the same time. If you have any other proposal, just add a letter and your proposal. In my case, I'd vote for 1.a and 2.a .

I like idea to have way to get package versions, that can be used either in conditions, either in other places as values for variables. +1 for 1.a. -- Regards -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On mercredi, 31 mai 2017 20.07:26 h CEST Dominique Leuenberger / DimStar wrote:

On Wed, 2017-05-31 at 17:01 +0200, Antonio Larrosa wrote:

...

Just wondering... let's do a small poll. How would you call ... 1) The macro that has one argument (package name) and returns its version number?

a) pkg_version b) pkg_version_number c) package_version d) pkg_ver other?

a) pkg_version

...

2) The macro that has 3 arguments (package_name, operator, version number) and tests whether the condition is true or not?

f) pkg_vcmp (pkg_version_compare might even be the spelled out long variant if needed)

vcmp is also used by zypper for example for a very similar action; having the same acronym sounds reasonable to me.

cheers, Dominique

For the same reason a) and f) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On May 31 17:01 Antonio Larrosa wrote (excerpt):

Just wondering... let's do a small poll. How would you call ... 1) The macro that has one argument (package name) and returns its version number? a) pkg_version b) pkg_version_number c) package_version d) pkg_ver other?

c) package_version because I prefer readability over abbreviations because in the whole IT we have way too many abbreviations.

2) The macro that has 3 arguments (package_name, operator, version number) and tests whether the condition is true or not? a) pkg_version_test b) pkg_version_check c) pkg_version d) is_pkg_version e) test_pkg_version other?

other because I would like to see a word that is already commonly used for comparison functionality like "if" or "cmp" i.e. something like package_version_compare or for those who think abbreviations are really better: pkg_version_cmp pkg_ver_cmp pkg_vcmp pvcmp pvif pif nice to see how abbreviations make things more and more incomprehensible ;-) Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2017-05-31 12:33, Antonio Larrosa wrote:

...

...

%pkg_version_not_equals : package != version

So, any opinion/suggestion about these macros?

So much to type. Can't we just have something similar to %requires_ge, _gt, _le, _lt, _eq, _ne?

I thought about that, but it's not actually a "requirement"

Note the "similar to" ;-)

I also thought about using %pkg_version_ge _gt ... but [..] more readable and you read the code more times than you write it :). I'm open to change the names in that sense though if it's generally accepted that those names are preferred.

...

(Besides "not equals" being grammatically incorrect...)

Ouch, thanks for noticing, I'll change that to _not_equal.

That's my point - writing it out using natural language inherently leads to "inconsistencies". ("equals" and "not equal" is one, "less than" and "at most" is the other. This is why I instantly thought of LT and LE instead.) Some of the spec generators floating around also use the symbolic notation (<=, =>) from the get-go without having to resort to lt/gt/etc. I think it was %{rubygem_requires blah >= 5}. If your pkg_version macro could even do that, that would be even better than having to discuss not_equals, not_equal and NE. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 31/05/17 20:20, Neal Gompa wrote:

Then again, I'm not sure how much "working with upstream projects" is promoted in openSUSE compared to Fedora (where most of my packaging experience comes from).

Its strongly encouraged and recommended wherever possible :-), so the number of patches we have sitting around indefinitely should be small, the number of patches sitting around until the next release of upstream software can be much higher though. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Wed, May 31, 2017 at 10:12 AM, Dominique Leuenberger / DimStar wrote:

On Wed, 2017-05-31 at 06:50 -0400, Neal Gompa wrote:

...

Not that I don't appreciate the technical ingenuity that is involved in making these kinds of macros, but this feels like miles of bad road. It makes it really easy for people to do dumb patches and then just let them build up. And among other things, conditional patch application makes for builds with more "surprises" in them.

I also feel like this just makes it easier to not try to properly fix things. In my experience, most of the time, a proper fix for things like compiler/Qt issues typically don't break older compilers or Qt versions.

In general, I think we should be doing *way less* conditional patching, not more.

Then again, I'm not sure how much "working with upstream projects" is promoted in openSUSE compared to Fedora (where most of my packaging experience comes from).

Conditional patches certainly have to be the exception - but every so often you find upstream porting stuff to a new version of libFOO and just requiring it afterwards. Because they can.

We often build a package for multiple versions and try to care not only for 'newest' - just think about Leap, where a lot of things is not 'fresh of the press'

So if we have a pkg A that builds with libFOO in Leap, then in TW with get an update of libFOO+n and A's upstream simply ports to that API, without actually caring for backwards compatibility (and yes, those are many) - we can apply the UPSTREAM patch on our package without breaking the Leap build - because there we don't apply it.

Or... you know, just only develop to target Factory. The model you present makes it hard to enforce a factory-first model. When you are backporting from "the future" (as Factory is, relative to Leap/SLE), it makes sense to branch the package for "the past" (relative to Factory) and incorporate the patches that way. The back-and-forth is not sane.

And instead of quering the 'suse_version' as we did so far, we actually immediately gain the advantage that somebody building a branch somewhere with newer packages of libFOO added, the patch will be automatically applied.

(The example of course only holds true for libFOO being API incompatible to libFOO+n - and A's upstream simply dropping support for libFOO in favor of libFOO+n)

But it's still better than all the variants of %if %{suse_version} - where basically almost NEVER is the SUSE target version really the identifying factory for some change - so those macros help align the code to what the writer actually really wanted in first place (

It seems like this is being made more complicated than it should be. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 31/05/17 12:56, Olaf Hering wrote:

Am Wed, 31 May 2017 12:23:13 +0200 schrieb Antonio Larrosa :

...

Which is actually what you want to do: apply your patch when the gcc version is 7.0 or newer. I think this makes spec files more readable and require

Is that 'gcc.rpm is 7.0' or 'gcc-7 binary is available'?

The macros just work with package names or "provided" capabilities so "gcc" as that's the package name.

I think it encourages people to not fix the actual code.

Can you be more explicit? Why would those macros encourage not to fix anything?

It will likely break 'quilt setup', like most conditionals in %prep do.

That's a good point. Although I'm not sure why these macros make the problem worse than it currently is, and if you're complaining about conditionals in %prep in general and how they break quilt, I guess that should be discussed in another thread. Just not to mix issues. -- Antonio Larrosa