Re: [Rpm-maint] [rpm-software-management/rpm] BuildRequires does not support boolean operators (#1216)

[Jeremy Siadal]

Closed #1216.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1216#event-3334764642___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] BuildRequires does not support boolean operators (#1216)

[Jeremy Siadal]

Thanks for the fast response. I have to take a mea culpa on this one; I went to 
rerun the build for exact output and it worked. I spent two hours this morning 
on two different servers and couldn't get this to work. It works now and I have 
no idea what changed.

FYI, I went through docs on rpm.org and fedora before posting the issue. 
Requires, Recommends, and the other dependencies were explicitly listed as 
supporting Booleans, but BuildRequires was noticeably missing. With the issues 
I was having, I concluded it may have been left out.

In any case, I'll close this issue. Thanks!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1216#issuecomment-628374503___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpm --eval "%{lua:rpm.interactive()}" does not immediately print the output (#1215)

[Miro Hrončok]

This gets the job done:

```python
from ctypes import cdll, c_char_p
librpmio = cdll.LoadLibrary("librpmio.so.9")
librpmio.rpmluaRunScript(None, c_char_p(b"rpm.interactive()"), None)
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1215#issuecomment-628278283___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: Convenient %version without tilde macro (#1219)

[Miro Hrončok]

@ignatenkobrain has has created this in Fedora's rust-srpm-macros:

```lua
%version_no_tilde() %{lua:
local sep = rpm.expand('%1')
local ver = rpm.expand('%2')
\
if sep == '%1' then
sep = '-'
end
\
if ver == '%2' then
ver = rpm.expand('%version')
end
ver = ver:gsub('~', sep)
\
print(ver)
}
```

I'd like to have something like this part of the standard issued macros. 
**However**, I think the default should be empty separator for 2 reasons:

 - the name of this macro suggests there is no tilde, not that the tilde is 
replaced with anything
 - it seem incredibly hard to pass an empty string as a macro argument (I 
haven't figured out how to do that yet)

WDYT?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1219___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: Lua rpm.error() function (#1218)

[Miro Hrončok]

I'd kindly like to request that the following Lua/RPM code:

```lua
rpm.expand("%{error:...}")
```

Could be made simpler with something like:
```lua
rpm.error("...")
```

Please do let me know if there is an existing better idiom for this.

(Possibly also with `warn` and `echo`.)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1218___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: Convenient version comparison macro (#1217)

[Miro Hrončok]

Hello. I had a recent discussion with @Conan-Kudo about version comparison in 
spec conditionals.

https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/467NMLL3DTRZQBEX5LPFU6ZD5P56SSF3/

So I dug a bit and found the excellent `rpm.vercmp()` Lua function. 
Unfortunatelly, using this in spec seems a bit complicated:

```spec
%if %{lua:print(rpm.vercmp(rpm.expand("%python3_version"), "3.9"))} >= 0
```

Hence, I was thinking there might be a `%vercmp` convenient macro.

It could either just expose the Lua function:

```spec
%if %{vercmp %{python3_version} 3.9} >= 0
```

However, while at it, it could be even more clever:

```spec
%if %{vercmp %{python3_version} >= 3.9}
```

I have come up with this, which is not very nice code, but it gets the job done 
apparently:

```lua
%vercmp() %{lua:
local first = rpm.expand("%1")
local op = rpm.expand("%2")
local second = rpm.expand("%3")
if (first == "%1") or (op == "%2") or (second == "%3") then
rpm.expand("%{error:%%vercmp needs three argument}")
end
if not (op:match("^[<>=!]?=$") or op:match("^[<>=]$")) then
rpm.expand("%{error:%%vercmp second argument must be a comparison 
operator}")
end
local cmp = rpm.vercmp(first, second)
print(((cmp == 0 and op:match("^[<>=]?=$")) or (cmp == -1 and op:match("<=?")) 
or
  (cmp == 1 and op:match(">=?"))or (cmp ~= 0 and op == "!=")) and 1 or 0)
}
```

So I was wondering whether such macro could be added to the standard macro 
selection. If this is not the place, I'll offer it to redhat-rpm-config macros.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1217___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] BuildRequires does not support boolean operators (#1216)

[Igor Raits]

Can you provide a reproducer? We use rich dependencies in BuildRequires at 
least in 2000 packages in Fedora.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1216#issuecomment-628197916___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] BuildRequires does not support boolean operators (#1216)

[Jeremy Siadal]

When using the following tag:
BuildRequires: (pkgA or pkgB)
rpmbuild will flag "(PkgA," "pkgB)", and "or" as not found. Removing the 
parenthesis doesn't resolve the issue. Tested with rpmbuild 4.13 and 4.15.1.

It doesn't seem logical to support the use of boolean operators on installation 
dependencies at run time, but not to support them at build time. If not 
supporting this is by design, then rpmlint is failing to flag the use of 
conditionals in BuildRequires as an error.

I discovered this while building an RPM with a dependency met by either an OS 
package or the package provided by the product vendor using a different name. 
Neither RPM "Provides" anything other than their own package names. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1216___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)

[Panu Matilainen]

In the same vein, rpm can also replace previously added elements behind your 
back in some cases (although I doubt dnf actually runs into that situation). 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1214#issuecomment-627930191___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)

[Panu Matilainen]

Oh and to clarify this:
> When I created any transaction element in rpm (ts.addErase(tsi.pkg.idx)) I 
> expect that the transaction element will not disappear.

Rpm *will* just ignore that added erasure if that package was already added 
into the set, whether directly or indirectly (via obsoletes or upgrade).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1214#issuecomment-627928916___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)

[Panu Matilainen]

There seems to be a rather fundamental misunderstanding  of the API here. 
Adding something into rpm transaction can (and will) create any number of 
additional transaction elements as a side-effect, this has always been the 
case. If you assume 1:1 relation between add*Foo() and what's in the 
transaction, yes there will be problems.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1214#issuecomment-627920860___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)

[Jaroslav Mracek]

Please could you look at dnf/db/group.py:_populate_rpm_ts()? There you will see 
that for each element in swdb we created a single rpm transaction element. The 
problem is when transaction elements do not match after transaction.
When I created any transaction element in rpm (ts.addErase(tsi.pkg.idx)) I 
expect that the transaction element will not disappear.

Is it clear now?

I need to know - is transaction disappearing behaviour a bug (I believe that 
this a bug)? If this is a feature I need to know how to detect disappeared 
transaction item and a reason.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1214#issuecomment-627909695___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Allow additional data parameter for ts.addErase(name) (#1213)

[Panu Matilainen]

I know dnf does that, it's what unearthed this bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=1620275, fixed in commit 
a144c29831a39ed303d6ea8d2ae91e1c36d64c84.

Rpm simply ignores those separate erasure elements as it has to keep track of 
the update relations.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1213#issuecomment-627908863___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Allow additional data parameter for ts.addErase(name) (#1213)

[Jaroslav Mracek]

In dnf-4 it is clear. We create for each operation a separate transaction item. 
Upgrade is not a single operation but operation of upgrade and upgraded. See 
dnf/db/group.py:_populate_rpm_ts().

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1213#issuecomment-627904084___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpm --eval "%{lua:rpm.interactive()}" does not immediately print the output (#1215)

[Miro Hrončok]

Can I do anything to have the interneter not in the macro expansion mode?

Dne st 13. 5. 2020 11:03 uživatel Michael Schroeder <
notificati...@github.com> napsal:

> This happens because you're in a macro expansion, so all the output is
> collected and returned to the macro engine.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1215#issuecomment-627859734___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpm --eval "%{lua:rpm.interactive()}" does not immediately print the output (#1215)

[Michael Schroeder]

This happens because you're in a macro expansion, so all the output is 
collected and returned to the macro engine.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1215#issuecomment-627852393___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpmfiArchiveRead() use signed return value to handle -1 on error (#1188)

[Panu Matilainen]

Merged, what's one more API bug when we already have many of the same.

Thanks for the patch!

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1188#issuecomment-627822704___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpmfiArchiveRead() use signed return value to handle -1 on error (#1188)

[Panu Matilainen]

Merged #1188 into master.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1188#event-3330849809___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpmfiArchiveRead() use signed return value to handle -1 on error (#1188)

[Panu Matilainen]

> I actually modeled this on read(2) which also takes a size_t as count 
> argument, but returns an ssize_t as response.

The problem is, read() (and write() for that matter) are dreadful APIs. I think 
APIs should be designed to be easy to use correctly and hard to misuse, and 
these both are the opposite due to the sign mismatch. It's like the deitys of 
Unix were feeling bored and threw a curveball to see just how many subtle ways 
to get it wrong people would come up with.

A little misdesign never prevented anybody from copying though, looking closer 
I see rpm itself already duplicates this API bug in several places, including 
the underlying rpmcpioRead() call, and Fread() and Fwrite() underneath those. 
The things ones memory protects you from...

>  If we're worried about range on 32 bit systems, we could also make it an
int64_t, or the caller should just call multiple times?

This is expected to be called multiple times as it is. 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1188#issuecomment-627822033___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint