Re: [Rpm-ecosystem] RFC #417 %optional file attribute

[Pascal Terjan]

On Mon, 26 Mar 2018, 11:44 Florian Festi,  wrote:

> Hi!
>
> We are currently pondering about #417 [1]. For adding a %optional file
> attribute that would allow adding file to to %files sections that may
> not be built under some circumstances (e.g. some architectures).
>
> It is already perfectly legal to have files not listed explicitly if
> they are within a directory that is included in the %file section. But
> some packages (examples wanted) may have trouble using this due to the
> way the package files are laid out.
>
> Otoh %optional would be another spec language key word that packagers
> have to deal with and we as RPM upstream developers have a hard time
> judging whether the benefit of the attribute really out weights the cost
> of bloating the spec language.
>
> Any input - especially with real world packages that would benefit such
> an addition - is welcome.
>

I personally don't remember missing it in 17 years creating rpm packages
and would suggest against using it in distro policy even if it was
available.
If one file depends on a feature available only on some architectures for
example, using it would mean the packager not noticing that it got disabled
on another arch where it is supposed to exist.
I prefer always being explicit and having explicit conditions defining in
which case the file should be there.

Florian
>
>
> [1] https://github.com/rpm-software-management/rpm/pull/417
>
>
>
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping

[Pascal Terjan]

On 3 February 2017 at 12:14, Panu Matilainen  wrote:
>
> Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of a
> larger and livelier audience...
>
> - Panu -
>
>  Forwarded Message 
> Subject: [Rpm-maint] Fixing macro scoping
> Date: Mon, 23 Jan 2017 12:30:21 +0200
> From: Panu Matilainen 
> To: rpm-ma...@lists.rpm.org 
>
>
> Consider the following snippet, originating from
> https://bugzilla.redhat.com/show_bug.cgi?id=552944:
>
> %{!?foo: %define foo bar}
> %define dofoo() true
> echo 1: %{foo}
> %dofoo
> echo 2: %{foo}
>
> I'd assume everybody agrees both %{foo}'s should evaluate to the same value,
> but that is not the case currently. Using a cli-variant of the above:
>
> [pmatilai@sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo: %define
> foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
> warning: Macro %foo defined but not used within scope
>
> bar
> true
> %foo
>
> The flaw here is that rpm supposedly implements block level scoping for
> macros (so in the above example, "foo" would only exist in the {!?foo:...}
> block), but doesn't actually enforce that, unless a parametric macro is
> "called". Current rpm warns about it, but warnings or not this behavior
> doesn't make the slightest sense.
>
> The question is, what do you think %{foo} should evaluate to in this case?
>
> Fixing it to honor the strict "block scoping" concept is not hard, now that
> the scoping level is honored from Lua too (see
> https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
> In this case the above reproducer would emit
>
> %foo
> true
> %foo
>
> Another option is slightly changing the whole scoping notion: parametric
> macros require locally scoped macros for the automatic argument macros like
> %#, %* and %1 anyway (it's flawed too currently, see below). So perhaps the
> macro scoping should follow the current "call level", ie a macro defined
> inside a parametric macro body is local to that macro, and everything else
> is global. In this case the reproducer would emit
> bar
> true
> bar

My first reaction was to prefer this one because '%{!?foo: %define foo
bar} has been used in tens of thousands of packages and sort of worked
"forever"
But replacing define with global is not very hard so no strong opinion...

> I have implementations for both and also a personal opinion, but I'd like to
> hear what others think.
>
> The related flaw is whether locally scoped macros should be visible to
> deeper nesting levels. Currently everything is, including those automatic
> macros:
>
> $ rpm --define '%bar() Bar %#: %{?1} %{?2}' --define '%foo() Foo %#: %{?1}
> %{?2} %bar a' --eval '%foo 1 2'
> Foo 2: 1 2 Bar 1: a 2
>
> I'd consider this a bug, %2 should not be defined within %bar() since it did
> not receive two arguments. So IMO the correct output in the above should be:
> Foo 2: 1 2 Bar 1: a

Yes that's indeed very unexpected as I have always considered %n to be
referring to the parameters of current macros
All %n > %# should be cleared at the same time %# is set

> But what about a macro manually %define'd within %foo() - should that be
> visible in %bar()?

I would expect so
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm -q --whatrequires and rich deps

[Pascal Terjan]

On 7 April 2016 at 11:49, Miroslav Suchý  wrote:
> Dne 7.4.2016 v 11:17 Michael Mraka napsal(a):
>
>> How does this work in other distributions?
>>
>> I'd like to hear your unbiased opinion that's why I don't include
>> neither my preferences nor current rpm behavior for now.
>
> In rpm I would like to have semantic "which package will stop working if I 
> remove this package". I.e. when I run:
>   rpm -e foo
> then I will get some errors that foo cannot be removed because A,B and C 
> requires it. I would expect that --whatrequires
> gives me the same list (sans transitive requires).
>
> So in your example:
>> An example to think about - have a package with following requires installed
>>   richdep.spec:
>> Requires: A
>> Requires: B
>> Requires: (C and D)
>> Requires: (E or F)
>> Requires: (G if H else I)
>>
>> Which of the following queries should include 'richdep' in the output?
>> rpm -q --whatrequires A
>> rpm -q --whatrequires B
>
> richdep for both above.
>
>> rpm -q --whatrequires C
>> rpm -q --whatrequires D
>> rpm -q --whatrequires '(C and D)'
>
> richdep for all three
>
>> rpm -q --whatrequires E
>> rpm -q --whatrequires F
>
> none

What if only one of them is currently installed?

>> rpm -q --whatrequires '(E or F)'
>
> richdep
>
>> rpm -q --whatrequires G
>> rpm -q --whatrequires '(G if H)'
>> rpm -q --whatrequires '(G if H else I)'
>
> for all three: richdep if *I* have H installed, otherwise none
>
>> rpm -q --whatrequires H
>
> none
>
>> rpm -q --whatrequires I
>
> richdep if there is no H installed on my machine, otherwise none
>
> Just my 2 cents.
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> ___
> Rpm-ecosystem mailing list
> Rpm-ecosystem@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem