Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

FYI: %setup permits multiple tar balls be unpacked into a buildsubdir.

Using a parameterized %setup() strips off arguments.

At some point, you are better off just not using %setup at all. Expand into 
shell commands that unpack (or checkout) whatever you wish.

There's also little reason why you cannot write a tool outside of rpm that 
creates a (possibly signed) tarball that Just Works with rpm.

-- 
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/368#issuecomment-350755890___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

@nim-nim: you can likely already do this, provided you have some means to 
overload %setup before the invocation in the spec file.

Macros are expanded before %setup is processed. So a definition like

%define setup %%setup -c -n whatever

will append (actually interpose, but you can use a parameterized macro if 
necessary to eat existing arguments/options).

You can also load the definition from macro configuration, and add 
%{?_setup_args} if that floats your boat.




-- 
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/368#issuecomment-350554474___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

@nim-nim OTOH, note that builds on a public branch (i.e. no authorization), 
downloaded through https/ssh (so small chance of maliciously modified),  on a 
tagged/documented check-in located in an upstream VCS repository, are entirely 
maintainable, as well as being consistent with RPM's goals of "reproducible 
builds".

Overloading %setup/%patch convolutes a reproducible build with obscure rpm 
macro configuration.

In fact, many slow-releasing upstream projects are already released through 
snapshot tar balls as above. The only difference with existing practice in 
packaging is through conventions in NVR naming to indicate a pre-release, and 
the tyranny of manually moving, say, a specific checkin forward by editing a 
maven-like SourceN: URL (as opposed to preparing a pre-release tarball, which 
can certainly be done already to simplify rpm packaging using %setup without 
overloading).

But perhaps I misunderstand the goals described here: 
[https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation](url)

-- 
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/368#issuecomment-350579988___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

The example is

%define setup() %%setup %{?_setup_args}

-- 
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/368#issuecomment-350566269___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

Read about parametrized macros in rpm installed docs (used to be 
/usr/share/doc/rpm-X.Y/macros, perhaps still is).

Basically a parameterized macro will parse all options/arguments to EOL into 
she'll-like transient macro 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/368#issuecomment-350565696___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

Finally -- overloading %setup like above is a hackers pathway away from 
reproducible builds into insanity. JMNSHO ...

(aside)
The real problem -- never well supported, but entirely achievable -- is

How to build from a VCS checkout (not a tarball) with minimal hassle?

This requires additional paraders like URL, authentication, repository name, 
branch, and checkout identifier (to name just a few of the additional 
parameters required).

All of the above additional parameters can be mapped into a SourceN: URL ... 
see what Maven does.

Parsing the URL and writing the script that does, say git clone or git pull 
would be _FAR_ more useful than overloading %setup.



-- 
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/368#issuecomment-350567149___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: macro for checking endianess (#365)

[Jeff Johnson]

Note also that adding an additional "informative" rpm macro to distro 
configuration is utterly trivial (if that is all you wish) and documenting the 
usage in distro packaging policy building a usage case.

Magically (and portably) detecting endianness within rpm build is trickier: 
consider cross compiling.

-- 
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/365#issuecomment-348789340___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: macro for checking endianess (#365)

[Jeff Johnson]

Presumably you are talking about an rpm macro since there are already C macros 
in .

I fail to see how knowing machine endianness in an rpm macro assists with 
packaging: patches could (and likely SHOULD) be written to include  
and test with a C macro rather than optionally applying a patch.

If you insist on adding Yet Another silly macro, please remember that 
endianness is now an executable, not a cpu, attribute. And that there are ways 
to change endianness at run-time and through emulators which are quite 
difficult to detect/implement correctly in rpmbuild.

-- 
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/365#issuecomment-348755846___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Fail to check signature (#270)

[Jeff Johnson]

TL;DR The 2nd headerReload() appends RPMSIGTAG_PADDING into a contiguous 
PROT_READ block.

-- 
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/270#issuecomment-348756410___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Fail to check signature (#270)

[Jeff Johnson]

Several points:

1) Your check for repackaged packages is what is running afoul of (what is 
obscurely known as) a "dribble", a tag appended to an immutable region, which 
is commonly found in repackaged packages (with a doubly linked upgrade chain 
tag appended) and in rpmdb headers (signature tags, and local installation 
data). You are correct that no *.rpm file has ever had a "dribble" appended, 
but there is nothing in a Header that prevents a "dribble" from being used.

2) headerReload() @rpm5.org does more than copy tags into a contiguous malloc. 
In fact, an anonymous mmap(2) is used, and mprotect(2) PROT_READ is done to 
prevent *all* changes to *any* header data returned as a pointer to the user. 
This also makes the pages used to store a Header RO, eliminates the silliness 
of HEADER_MINMEM permitting access directly into header data, and (as side 
effect) stops the overhead of swabbing all integer data on every headerLoad. 
Instead, data is swabbed during headerGet() returned as a malloc'd copy, to 
itemize just a few of the differences that prevent reasoning about the behavior 
from an identically named "headerReload" symbol.

3) RPMSIGTAG_PADDING can be used not only to reserve space for signatures, but 
also to insert block alignment between signature <-> metadata headers (useful 
for byte ranged HTTP), and (if also appended to the metadata header( between 
metadata <-> payload. Of course having the ability to do HTTP byte range 
retrievals suffers from "legacy compatibility" in a sense (backward 
compatibility is ensured by the format, but the "feature" cannot be assumed to 
exist in any given *.rpm without some other test).

There are yet other reasons to use a "dribble" in a *.rpm package, including 
unifying (by nesting immutable regions) signature <-> metadata Header's into a 
single blob.

Details are left in my imagination ;-)

-- 
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/270#issuecomment-348754764___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

[Jeff Johnson]

The literal request to append %setup_args (or %patch_args, same deal) to 
%setup/%patch is utterly trivial configuration: overload the existing %setup or 
%patch macros-in-C with any macro definition you wish.

Meanwhile, that isn't going to do anything very useful since neither %setup nor 
%patch is a single command: both are used to generate multiple lines of shell 
script, and simply overriding arguments does not provide sufficient scoping 
hints to tell how/where the overrides are to be inserted.

The tricky problem isn't %setup_args either, but rather the side-effect of 
setting the buildsubdir. You can already write other multi line macros that 
expand to whatever you wish, the problem being that you will also need an 
additional "cd %buildsubdir" at the beginning of %build/%install/%check 
scriptlets since not using %setup will not set set %buildsubdir.

Any rational attempt to change %setup will have to change the generated shell 
script template. Devising a new template requires explicit design and examples, 
not just an RFE for (entirely unspecified) additional arguments with a loose 
claim of "showing its age".

-- 
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/368#issuecomment-350508813___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

[Jeff Johnson]

The right place to fix conflicting names/usages between C and Python is in rpm 
python's init.py.

FWIW, each of those values is just a bit mask, you could easily create names in 
mock.

As easily, you could stop disabling signature/digest checking.

-- 
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/440#issuecomment-386692305___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

[Jeff Johnson]

The problem with probes (like your patch) is that RPM is attempting to run a 
dependency assertion checker whose values are known at the end of an 
installation, not at the beginning, by also checking added packages.

Since a /sys path is dependent on both a kernel capability as well as the mount 
being performed, and there are no details contained in added package metadata 
to help resolve the probe dependency, there likely would need to be disablers 
on the probe namespace when rpmtsCheck() is called to permit, say, the 
transition from a non-uefi -> a uefi based system that contained a probe 
dependency.

I personally do not think that the inability to resolve a probe dependency 
against added packages or depsolver metadata as the sine qua non, but YMMV. The 
point has been brought up in the past however.

-- 
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/pull/438#issuecomment-385044068___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

[Jeff Johnson]

You are asking about how file dependencies work? The requirement I suggested 
would be matched by an explicit Provides:, (not a path), in a kernel package 
that is capable of uefi?

That "works" (in the sense that it is all that RPM4 has ever done, matching R 
<-> P assertions contained in packages).

The patch is for a runtime probe however, and really needs to be done more 
generally, and not by polluting the rpmlib() code and namespace.

-- 
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/pull/438#issuecomment-385022297___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

[Jeff Johnson]

See the cpuinfo() (which parses /proc/cpuinfo) or the sysconf() (which can 
detect whether NPTL is used) namespaces as example probes in RPM5.

There is also a class of probes implemented as RWX() letter combinations as a 
thin wrapper onto access(2) calls on a path that would work for "system(UEFI)" 
probes as well.

-- 
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/pull/438#issuecomment-385027027___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Implement configurable, mandatory signature/digest verify level for rpm -K (ac280c4)

[Jeff Johnson]

Congratulations on a nice job!

I could quibble with details and approach, but replacing the insanity of "best 
effort" verification with a configurable policy driven mechanism is a HGE 
amount of work. Been there, done that ;-)

-- 
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/commit/ac280c42e3071cf46f3c4ea5fba2244c89a5cea9#commitcomment-28774565___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

[Jeff Johnson]

There is (perhaps) a way to use the context of the dependency assertion 
resolution to choose between two means of dependency resolution:

1) a namespace encapsulated virtual provide (think: Provides: system(EFI) in 
some package)

2) a Boolean valued dependency probe function (think: your implementation that 
tests if a path is a directory)

And then use the virtual provide when dealing with added/removed packages but 
otherwise use the Boolean valued probe function.

Disclaimer:
I'd need to diddle a bit of code to see whether the above complexity might 
address the major complaint against runtime/dynamic/probe dependencies as 
described previously.

-- 
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/pull/438#issuecomment-385098028___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] How to generate GNU make dependency file for a SPEC file automatically?

[Jeff Johnson]

> On May 11, 2018, at 7:31 AM, Francesco <francesco.monto...@gmail.com> wrote:
> 
> Hi Jeff, Hi all,
> I'm resuming this (old) topic in case somebody is interested, I created a 
> very small and simple Python utility 
> 
>   https://github.com/f18m/rpm-make-rules-dependency-lister
> 
> that does what I was describing in this topic: it allows to connect in a 
> slightly smarter way GNU make and rpmbuild,
> and to avoid unnecessary RPM re-packaging operations
> 
> HTH,
> Francesco
> 

Nice!

Hmmm ... it looks like you want (path,md5) pairs in GNU md5sum format. Is that 
correct?

If so, You might be able to simplify the code, using a utility like

https://www.guyrutenberg.com/2008/10/24/tarsum-calculate-checksum-for-files-inside-tar-archive/

An rpm payload is just a compressed cpio ball.

Feed that to something like the above utility to spew the Makefile dependencies.

Disclaimer: I haven't looked at the code, nor am I Python programmer. I'm just 
trying to remove the need to unpack the *.rpm payload.

hth

73 de Jeff
> 
> 
> 
> 2018-03-27 3:31 GMT+02:00 Jeff Johnson <n3...@me.com>:
>> 
>> 
>>> On Mar 26, 2018, at 6:15 PM, Francesco <francesco.monto...@gmail.com> wrote:
>>> 
>>> Hi Jeff,
>>> thanks for your reply.
>>> 
>>> 
>>> 
>>> 2018-03-26 19:04 GMT+02:00 Jeff Johnson <n3...@me.com>:
>>>> 
>>>> There isn't an explicit tool to convert rpmbuild dependencies to Makefile 
>>>> dependencies afaik.
>>>> 
>>>> OTOH, it's not impossibly hard to script a couple of missing pieces that 
>>>> are needed:
>>>> 
>>>> 1) Automate by rule generating a *.src.rpm from a (possibly modified) 
>>>> *.spec.
>>>> 
>>>> 2) Automate by rule installing a *.src.rpm into a local build directory. 
>>>> This requires configuring some rpm macros to map rpmbuild inputs/outputs 
>>>> into a single directory.
>>>> 
>>>> 3) Automate by rule rebuilding of binary *.rpm from a newer *.spec in the 
>>>> local build directory
>>>> 
>>>> You can find some useful rules using wild cards and % template rules in 
>>>> rpm5 sources: see the
>>>> tests/Makefile.am file for the pattern rules.
>>> 
>>> Honestly I'm not sure to understand what you mean... when you say "Automate 
>>> by rule" you mean writing a GNU make rule, right?
>> 
>> Yes.
>> 
>>> Then it's clear to me step 1 and 2 but is not clear why should I get a 
>>> newer .spec file in the local build directory only if some of my sources 
>>> have changed: if step 1 and 2 are always executed by GNU make (which btw 
>>> would be against my goal of running unneeded packaging operations) then I 
>>> guess that the mtime of the .spec file in the local build directory will 
>>> always change from run to run... what am I missing?
>> 
>> Sorry to be obscure. The pattern rules I wrote had 2 *.spec files: the top 
>> level *.spec determined when a *.src.rpm should be made, which triggered an 
>> install not a subdirectories, with a 2nd *.spec (copy) that triggers a 
>> rpmbuild by rule.
>> 
>> Does that make sense? worksforme, for the purposes I needed, QA testing of a 
>> just built version of rpm within the buil tree ...
>> 
>>> Also I'm particularly interested in binary-only RPMs (I need such a tool 
>>> for a commercial software)... to give you an idea, most of my RPM spec 
>>> install sections look like:
>>> 
>>> %install
>>> make -C ../mysources mytarget_install DESTDIR=%{buildroot}
>> 
>> That's pretty generic, yes. Meanwhile the real problem is that rpmbuild 
>> within Makefiles is kinda awkward.
>> 
>>>  
>>>> Alternatively, one could attempt generating a Makefile include rule.
>>>> 
>>>> Extract (and filter) rpmbuild dependencies from a spec (or *.src.rpm) 
>>>> file. RPM can query a spec file (or *.src.rpm), convert those (filtered) 
>>>> dependencies to package names, and convert the package names to file names 
>>>> that have a time stamp that can be included into a Makefile.
>>> 
>>> Sorry, I'm not sure I get this either... I know RPM allows you to query 
>>> dependencies but you can only query the package names listed under 
>>> "Requires:" isn't it?
>> 
>> Basically yes. But to automate within a Makefile (like dependencies on *.h)' 
>> the build requirements need to be mapped onto a file name that has a tim

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

[Jeff Johnson]

Sure it's easy to remove an underscore to adapt to picky pylint.

Here are several reasons for not doing so:

1) this is ancient legacy code copied from yum, whose devels wished speed and 
considered header digest/signature checking slow. In fact, disabling file 
digests is far more expensive. Been there forever too.

2) there is already means to set a macro to change the default vsf policy. That 
has been there forever too, set before creating a transaction.

3) signature/digest verification needs to be per-system (or per-chroot, 
per-vm), not per-application. There is also no attempt in the mock code to make 
the policy configurable, the policy values are hard wired.



-- 
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/440#issuecomment-388639131___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] How to generate GNU make dependency file for a SPEC file automatically?

[Jeff Johnson]

> On May 13, 2018, at 2:31 PM, Jeff Johnson <n3...@me.com> wrote:
> 
> 
> 
>> On May 11, 2018, at 7:31 AM, Francesco <francesco.monto...@gmail.com> wrote:
>> 
>> Hi Jeff, Hi all,
>> I'm resuming this (old) topic in case somebody is interested, I created a 
>> very small and simple Python utility 
>> 
>>   https://github.com/f18m/rpm-make-rules-dependency-lister
>> 
>> that does what I was describing in this topic: it allows to connect in a 
>> slightly smarter way GNU make and rpmbuild,
>> and to avoid unnecessary RPM re-packaging operations
>> 
>> HTH,
>> Francesco
>> 
> 
> Nice!
> 
> Hmmm ... it looks like you want (path,md5) pairs in GNU md5sum format. Is 
> that correct?
> 
> If so, You might be able to simplify the code, using a utility like
> 
> https://www.guyrutenberg.com/2008/10/24/tarsum-calculate-checksum-for-files-inside-tar-archive/
> 
> An rpm payload is just a compressed cpio ball.
> 
> Feed that to something like the above utility to spew the Makefile 
> dependencies.
> 
> Disclaimer: I haven't looked at the code, nor am I Python programmer. I'm 
> just trying to remove the need to unpack the *.rpm payload.
> 
> hth
> 
> 73 de Jeff

Here is another approach, using common system utilities:

https://stackoverflow.com/questions/16423484/get-checksum-of-files-inside-tar-archive-on-remote-host

There is an example there that doesn't need ssh, but you will need to  use 
rpm2cpio into cpio (modern GNU tar handles cpio?), as well as create the 
(path,md5) pair using awk/sed/etc.

Again: nothing wrong with your script, I'm just trying to avoid the rpm 
unpacking, as well as to simplify the need for Python as a build prerequisite 
in the Makefile rules.

hth

73 de Jeff
>> 
>> 
>> 
>> 2018-03-27 3:31 GMT+02:00 Jeff Johnson <n3...@me.com>:
>>> 
>>> 
>>>> On Mar 26, 2018, at 6:15 PM, Francesco <francesco.monto...@gmail.com> 
>>>> wrote:
>>>> 
>>>> Hi Jeff,
>>>> thanks for your reply.
>>>> 
>>>> 
>>>> 
>>>> 2018-03-26 19:04 GMT+02:00 Jeff Johnson <n3...@me.com>:
>>>>> 
>>>>> There isn't an explicit tool to convert rpmbuild dependencies to Makefile 
>>>>> dependencies afaik.
>>>>> 
>>>>> OTOH, it's not impossibly hard to script a couple of missing pieces that 
>>>>> are needed:
>>>>> 
>>>>> 1) Automate by rule generating a *.src.rpm from a (possibly modified) 
>>>>> *.spec.
>>>>> 
>>>>> 2) Automate by rule installing a *.src.rpm into a local build directory. 
>>>>> This requires configuring some rpm macros to map rpmbuild inputs/outputs 
>>>>> into a single directory.
>>>>> 
>>>>> 3) Automate by rule rebuilding of binary *.rpm from a newer *.spec in the 
>>>>> local build directory
>>>>> 
>>>>> You can find some useful rules using wild cards and % template rules in 
>>>>> rpm5 sources: see the
>>>>> tests/Makefile.am file for the pattern rules.
>>>> 
>>>> Honestly I'm not sure to understand what you mean... when you say 
>>>> "Automate by rule" you mean writing a GNU make rule, right?
>>> 
>>> Yes.
>>> 
>>>> Then it's clear to me step 1 and 2 but is not clear why should I get a 
>>>> newer .spec file in the local build directory only if some of my sources 
>>>> have changed: if step 1 and 2 are always executed by GNU make (which btw 
>>>> would be against my goal of running unneeded packaging operations) then I 
>>>> guess that the mtime of the .spec file in the local build directory will 
>>>> always change from run to run... what am I missing?
>>>> 
>>> 
>>> Sorry to be obscure. The pattern rules I wrote had 2 *.spec files: the top 
>>> level *.spec determined when a *.src.rpm should be made, which triggered an 
>>> install not a subdirectories, with a 2nd *.spec (copy) that triggers a 
>>> rpmbuild by rule.
>>> 
>>> Does that make sense? worksforme, for the purposes I needed, QA testing of 
>>> a just built version of rpm within the buil tree ...
>>> 
>>>> Also I'm particularly interested in binary-only RPMs (I need such a tool 
>>>> for a commercial software)... to give you an idea, most of my RPM spec 
>>>> install sections look like:
>>>> 
>>>> %install
>>>&g

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

[Jeff Johnson]

Then use the constant in rpm (w the leading underscore that means something 
different to Python than C) to create whatever name you wish in init.py.

-- 
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/440#issuecomment-387147907___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

[Jeff Johnson]

Again: you could easily stop disabling signature/digest checks in mock.

-- 
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/440#issuecomment-387148689___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Proposal for rpmbuild patch

[Jeff Johnson]

> On May 17, 2018, at 1:38 PM, Francesco  wrote:
> 
> Hi all,
> [I posted a similar proposal under the thread "How to generate GNU make 
> dependency file for a SPEC file automatically?" but I'm reposting here with a 
> better subject]
> 
> Proposal: add a new option to rpmbuild, something like   
> --generate-md5sum= that writes the md5sum (or whatever other 
> hash, sha1sum, etc) of all files placed inside the RPM package. Of course the 
> hash would be that associated to the file prior to cpio compression, after 
> all other rpm processing (e.g., stripping of debug info), just before it gets 
> compressed.
> 

You do realize that rpm already computes a digest (usually SHA256, but MD5 can 
be configured) for all files in a *.rpm package file? That information can be 
retrieved using --queryformat easily (if make can use digests other than MD5).

Meanwhile -- for general adoption/use in Makefiles -- the glue to generate make 
dependencies should be as simple as possible. The conversions involved with 
compression, archive format, and digest algorithm are all obvious, but there 
really isn't good support to do the operations on a pipe with an archive.

> Rationale: with some simple post-processing such new option would allow to 
> e.g., find in a way transparent to the build system employed by the user 
> (automake, cmake, etc) to understand if a .rpm needs to be regenerated 
> (because some of its packaged files have been changed) or not.

The biggest issue(s) I see are:

1) generating another artifact (other than *.rpm) from rpmbuild would be quite 
awkward.
rpmbuild (unlike gcc) is 2 layers (shell and %buildroot) from the build tree, 
and packaging occurs long after the compilation, unlike gcc.

2) rpm has way too many obscure CLI options already. So instead of a CLI 
option, the approach should be through a configuration macro, using a 
rule-based value/pattern to generate the output location. A CLI option can 
always be retrofitted using popt(3) aliases.

But a separate executable, not directly integrated into rpmbuild, might 
simplify the decompression/archive/digest handling with stdout output, making 
it easier to automate make dependencies on *.rpm contents, since rpm already 
has all the necessary implementations.

hth

73 de Jeff

___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

@svpv: good for ROSA, and conversations with me might be partly responsible for 
the choice. Using the same epoch when one value is missing has the distinct 
advantages (aka "epoch promotion") enumerated below:

1) entirely consistent behavior with what the Debian Borg enclave advocates
2) epoch isn't forever: epoch becomes part of the comparison only when explicit 
and automatically is ignored when not present, either because versioning became 
"sane" after some hiccup, or because sloppy packaging/packagers has composted 
the original reason for an epoch.

OTOH, defaulting a missing epoch to 0 has the following advantages:

1) missing epoch is 0 is trivial to explain doing support
2) returning 0 instead of "not present" eliminates an error that application 
developers have forgotten to handle
3) the epoch comparison value returned is less contextually sensitive, all 
epoch values are WYSWYG

One can devise extreme/confusing counter example failure cases for either 
choices of a default value for a missing element rather easily.

(asides)
What really needs to happen going forward in RPM is to change epoch to a string 
from an integer so that the rpmvercmp() comparison is identical for each member 
of the {E,V,R} tuple and patterns might reasonably used for epoch as well. 
YMMV, everyone's does.

-- 
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/450#issuecomment-400341017___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

One last comment on missing values in EVR tuple S ...

Whatever scheme is implemented for RPM comparison with missing values, the 
following pathological dependency with all values missing SHOULD behave 
naturally:

Requires: foo >= :-


-- 
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/450#issuecomment-400351755___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

Extreme or not, RPM is expected to deal with missing values (not only 
optional/missing epoch) sanely and intuitively, you aren't the first to 
complain.

Fix the issue and *SOLVE* the engineering problem(s) instead of

1) claiming that "epoch promotion" doesn't "work" with clear history to the 
contrary
2) pointing out that distributions are not maintaining upgradeability by 
changing epochs across major releases
3) suggesting new fangled special case ornamentation like '*' that does 
whatever you want the comparison to do
4) begging the question by ignoring other similar problems with missing values 
in EVR

all of which has been attempted/suggested in this thread.

For the specific case I gave, with all values missing, one could certainly 
demand that at least one of EVR be present while parsing a dependency.

Any comparison system that permis missing values MUST supply 
sane/natural/intuitive defaults for missing values, or attempt explicit data 
validation checks to prevent illformed/invalid/indeterminate/unexpected results 
when comparing.

Or we will be discussing the mysterious epoch behaviors for another decade or 
two.

-- 
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/450#issuecomment-400381957___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

[Jeff Johnson]

Good riddance: Ptooey!

There is one last improvement that might be attempted.

RPM invokes gpg to sign plaintext blobs from packaging.

Because of the handoff to a gpg helper, it is possible for a signature to be 
undertaken on a digest (like MD2/RIPEMD etc) that the rpm internal gpg 
signature verification  does not implement.

RPM will of course fail to verify a signature on an unimplemented digest 
algorithm. The problem that remains is that the error happens too late to be 
usefully informative.

The better implementation in rpm would be to check for supported/implemented 
digests when the signature is returned from the gpg helper in order to provide 
immediately useful error messages to the package signer.

-- 
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/commit/ff4b9111aeba01dd025dd133ce617fb80f7398a0#commitcomment-29504410___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: use kernel/keyutils key rings as a backing store for rpm keyrings (#454)

[Jeff Johnson]

One of the problems with having secrets like passwords/privkeys within 
application memory is the risk of loss through a segfault core dump or /dev/mem 
/proc snooping.

Complete opaque isolation to prevent loss can be attempted with TPM and/or 
other attached hardware, or by handing off signing to helpers like gpg which 
have their own means to protect against secret loss.

There is still the problem of how to convey a password/privkey from RPM to 
another device: the password will be resident within RPM memory.

One way to minimize the risk of secrets being snooped while resident in RPM 
memory is to use keyutils and linux kernel key rings. The keyrings can be used 
to pass values to/from rpm execution, and the time that the secrets are present 
in rpm memory can be minimized by accessing/using/erasing the secret within a 
more limited scope than the entire lifetime of an rpm process, simplifying 
audits and minimizing risk.

The keyutils interface is quite simple, and the few places where passwords (or 
pubkeys) are stored in RPM could/should be replaced with an access/use/erase 
implementation.

I can supply code pointers or even an implementation if interested.


-- 
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/454___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

[Jeff Johnson]

And to partially answer why MD2/RIPEMD were implemented:

MD2 as one of the first digests used is (or was) universally available in all 
backends (including gpg)

RIPEMD has (or had) usage cases in *BSD systems, and in Europe, with 
OS/continental chauvinistic attachment to the algorithm. It was easier to add 
RIPEMD than it is/was to discuss the One True/Best Algorithm to use.

Times have changed, but ECDSA and SHA3 will surely follow the same historical 
trajectory somewhen.

-- 
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/commit/ff4b9111aeba01dd025dd133ce617fb80f7398a0#commitcomment-29504513___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: permit HMAC-XXX for digest XXX (#455)

[Jeff Johnson]

While we are on the topic of message digests ...

Much development time in RPM is spent handling multiple digests as well as 
moving away from older digest algorithms like MD2/MD5/SHA1 towards longer (and 
slower) SHA2 algorithms. While the rate of forward progress is mostly 
determined by adoption throughout the rpm (and distro) ecosystems, there are 
some simple implementations (I.e. HMAC) that can help mitigate the risk of 
collisions (and tampering of *.rpm content).

HMAC is essentially a transform, a digest of a digest with an inner/outer key 
salt, that can be implemented generically for all currently implemented digests 
in RPM.

HMAC provides better protection against length extension attacks on digests.

Legacy compatibility with existing versions of RPM could be handled either by 
backporting, or by careful phase-in.

One of the immediate usages might be to handle FIPS library 
generation/verification within rpm and rpmbuild, unifying RPM and FIPS 
verification.

-- 
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/455___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#456)

[Jeff Johnson]

Another lurking/lingering RFE digest issue

RPM traditionally used MD5 file digests, long since generalized to use SHA256 
(or other) digest from rpmbuild macro configuration. Digest verification can 
also be enabled/disabled using %verify/%defverify.

Adding a string->value table for known/implemented algorithm names that also 
set the digest algorithm to use in RPMTAG_FILEDIGESTALGOS would permit packager 
specification of the desired digest algorithm in %verify/%defverify, with a 
%verify parsing extension to permit the names in the table to appear within 
%verify() option attributes.

The table of permitted algorithms -- which might be different than the 
implemented algorithms -- would be specified by a colon separated tuple in a 
macro. And if absolutely essential to control for whether the build master or 
the packager determines what algorithm to use, the search precedence of build 
master or specfile to determine algorithm can be done in another macro.

For verification display purposes, the name of the verify algorithm used 
could/would be prepended to the hex output, like "sha1:12345...". If preserving 
*EXACTLY COMPATIBLE* output for scripts etc, there would need to be Yet Another 
macro disabler to preserve legacy compatibility.

Been on my todo list for a long time. I can supply code if interested.

-- 
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/456___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#457)

[Jeff Johnson]

Another lurking/lingering RFE digest issue

RPM traditionally used MD5 file digests, long since generalized to use SHA256 
(or other) digest from rpmbuild macro configuration. Digest verification can 
also be enabled/disabled using %verify/%defverify.

Adding a string->value table for known/implemented algorithm names that also 
set the digest algorithm to use in RPMTAG_FILEDIGESTALGOS would permit packager 
specification of the desired digest algorithm in %verify/%defverify, with a 
%verify parsing extension to permit the names in the table to appear within 
%verify() option attributes.

The table of permitted algorithms -- which might be different than the 
implemented algorithms -- would be specified by a colon separated tuple in a 
macro. And if absolutely essential to control for whether the build master or 
the packager determines what algorithm to use, the search precedence of build 
master or specfile to determine algorithm can be done in another macro.

For verification display purposes, the name of the verify algorithm used 
could/would be prepended to the hex output, like "sha1:12345...". If preserving 
*EXACTLY COMPATIBLE* output for scripts etc, there would need to be Yet Another 
macro disabler to preserve legacy compatibility.

Been on my todo list for a long time. I can supply code if interested.

-- 
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/457___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: permit HMAC-XXX for digest XXX (#455)

[Jeff Johnson]

As always I can provide pointers to code, and can do an implementation if 
interested.

-- 
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/455#issuecomment-400434021___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

[Jeff Johnson]

Presumably the "basic parameters" validation you are referring to is 
makeSigTag() in sign/rpmgensig.c where the returned signature is parsed and 
values are sanity checked.

That check will not prevent a signature using, say, MD2 from being added to a 
package.

The hash (and signing) algorithms which are "supported" by rpm need to also be 
checked so that the signer, not the consumer, of a package can be notified that 
an unverifiable (by rpm) signature has just been generated by the gpg helper.

-- 
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/commit/ff4b9111aeba01dd025dd133ce617fb80f7398a0#commitcomment-29518382___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] check that libcrypto supports MD2 (#453)

[Jeff Johnson]

Removing MD2 everywhere -- BeeCrypt, NSS, and OpenSSL -- in wrappers should be 
done for consistency: but that's perhaps out-of-scope for this OpenSSL specific 
pull request.

-- 
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/pull/453#issuecomment-45961___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] check that libcrypto supports MD2 (#453)

[Jeff Johnson]

OpenSSL requires MD2 because BeeCrypt in RPM unconditionally supplied MD2, 
feature parity.

BeeCrypt implemented MD2 because -- at the time -- MD2 was still used but 
already known broken, legacy (and standard) compatibility.

RPM implemented MD2 because it was there, feature completeness.

The modern practice of optional features tied to exposed library symbols that 
are not enabled because of "security reasons" forces not only extraneous 
configure options, but also complicated library versioning and packaging 
dependencies.

The best approach IMHO would be run-time, not build time, detection of MD2. 
This is perhaps doable with weak symbols or vectors to stub-in missing symbols 
that OpenSSL has removed.

One can alternatively carry around configure detection and conditional 
compilation. But that also forces rpm to track with the ever evolving OpenSSL 
API, most of which rpm does not (and will not ever) need.

Simplest of all would be to rip out MD2 everywhere in RPM.

-- 
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/pull/453#issuecomment-399986673___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

You are 15+ years too late to discussions about EVR comparison.

Panu wasn't even much of a participant: I was.

I summarized the issue above.

A choice was necessary between 2 possible schemes for supplying a default value 
for a missing epoch. I made that choice when I implemented the code.

Endless (several year) explanations and discussions resulted, with no obvious 
consensus forming. Because one of the two obvious choices had already been 
made, there was only one other alternative choice. I too made that change, to 
support "A missing epoch is identical to 0".

There are no new issues to discuss. Flip flopping between two obvious choices 
for the default value of a missing epoch every few years cannot please 
everyone, and in fact will be more harmful than beneficial.



-- 
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/450#issuecomment-400284644___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] check that libcrypto supports MD2 (#453)

[Jeff Johnson]

What is the RPM need for checking if OpenSSL supports MD2? MD2 was broken a 
long time ago, and has few redeeming values as a cryptographic hash: e.g. MD2 
is pig slow.

-- 
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/pull/453#issuecomment-399793329___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

Dependencies are compared sequentially across the set {E,V,R} and 2 .GT. 0

That is what is implemented, and the RPM comparison is working exactly as 
expected. That isn't a bug.

-- 
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/450#issuecomment-399499941___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#457)

[Jeff Johnson]

Closed #457.

-- 
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/457#event-1702456413___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for librpm (#429)

[Jeff Johnson]

See #456 which might have minor ramifications for your project. Meanwhile you 
should attempt to handle RPMTAG_FILEDIGESTS general by looking at 
RPMTAG_FILEDIGESTALGO{,S} to determine what digest was used, and dispatching to 
the appropriate routine within Python code.

In practice, SHA256 is widely used, and the per-file tag array with an S 
appended is peculiar to RPM5 packaging atm.

-- 
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/429#issuecomment-400461227___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: actually implement --nomanifest* while installing packages. (#458)

[Jeff Johnson]

This is an extension of #437 ... I apologize for not being sufficiently 
specific before.

There are 2 code paths that will read manifest files recursively.

One (newer) code path uses lib/rpmgi.c and honors a query/verify disabler.

The other (older) code path is through lib/rpminstall.c needs to handle the 
same disabler.

See the original RFE for the reasons why there needs to be a disabler for 
reading manifests.

-- 
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/458___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

Ornamenting epoch values with explicit magic like '*' is irrelevant to this 
discussion about how a missing epoch in tar = 1.28 should compare to an 
explicit epoch in tar = 2:1.26.

For starters, epoch is a digit string followed by a ':', and '*' is a 
non-numeric character that pretends at DWIM pattern matching.

In fact, '2' would be the saner choice than '*' to solve the tar comparison 
issue.

-- 
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/450#issuecomment-400298924___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

@rpm-maint: the sole reason for the existence of epoch (and its higher 
precedence in the comparison order of {E,V,R}) is to preserve upgradeability 
when either upstream has made an inconvenient choice of version, or the 
packager/distro has decided to revert to an older version.

This has nothing to do with grievous burdens, and is entirely relevant to the 
real world of software distribution where mistakes can and do happen.

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

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

[Jeff Johnson]

Can you point me at validating basic parameters please?

If you were actually explicitly testing for permitted/implemented digest 
algorithms, then your patch would include the removal of MD2/RIPEMD160 there as 
well.

I also looked at the code and saw nothing that tests for "supported" (by rpm) 
digest algorithms.

-- 
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/commit/ff4b9111aeba01dd025dd133ce617fb80f7398a0#commitcomment-29513784___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

It is possible to construct failing counter examples for either obvious choice 
of missing epoch.

Your "strong recollection" cannot be analyzed further.

Truly I made the change at the time to simplify what I had to type multiple 
times a day doing support:
Missing epoch is identical to 0
Other answers required multiple interactions to identify exactly what was 
failing to meet expectations and deal with endless opinions of what SHOULD be 
done.

I believed then (and believe now) that ignoring comparisons with missing values 
is the superior implementation for missing epoch.

I also believe that exposing epoch values everywhere was a poor design choice 
in yum that has led to brain overload from too much information in the fog of 
"dependency hell".

But what's done is done, discussions be damned.

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

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#457)

[Jeff Johnson]

Apologies for the fat finger duplicate.

-- 
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/457#issuecomment-400458728___
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 -V lacks support for place holder packages or wildcards (#451)

[Jeff Johnson]

The tag=pattern syntax is undocumented for a reason: the implementation as a 
filter through a match iterator is clunky and low performing. Lots of headers 
are loaded, tags retrieved, pattern applied, and most headers are discarded.

The better implementation is to apply patterns directly to keys in an index, 
and then retrieve only those headers that match. The current interface 
retrieves all headers in an rpmdb in order to apply patterns to tags.

Documenting a clunky imperfect proof-of-concept interface in order to increase 
usage will quite predictably lead to bug reports about excessive I/O and low 
performance.

-- 
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/451#issuecomment-400573581___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: add a way to access the installed NVRA and install time without accessing an rpmdb (#459)

[Jeff Johnson]

There are many programs/applications that wish simple information about 
installed software, e.g. the HOST-MIB in net-snmp, or security checkers cross 
referencing to CVEs, where linking to rpm libraries and Berkeley DB are 
mind-numbing overkill.

One simple solution to supplying essentially "rpm -qa" in a dumbed down KISS 
fashion is to map NVRA onto the file system with an install time stamp.

A zero length file is sufficient for net-snmp. Other applications which might 
need more complex information can populate the contents with a --queryformat 
output.

The file can be maintained in sync with an rpmdb by creating/unlinking the file 
on the same code path as adding/erasing rpmdb headers.

I can supply pointers to code, and can do an implementation, if interested.



-- 
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/459___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] RFE: differentiate file and directory dependencies using a trailing '/' (#439)

[Jeff Johnson]

-- 
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/439___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Add --nomanifests disabler (#437)

[Jeff Johnson]

Good.

Meanwhile I suggest you look at the refactored lib/rpminstall.c 
tryReadManifest(). There is no logic there preventing the call.

-- 
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/437#issuecomment-384692929___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: differentiate file and directory dependencies using a trailing '/' (#439)

[Jeff Johnson]

RPM has only path and directory dependencies, largely because the path 
canonicalization in rpmCleanPath() always strips a trailing '/' character.

Luckily, the (arguably hacky) fix is not very complicated.

1) always over allocate paths by 1 byte to accomodate a trailing '/' (if 
necessary.

2) Copy the trailing character of the input argument to rpmCleanPath() to the 
return value when it's a trailing '/'

The above heuristic starts to propagate a hint to the expected file type 
throughout rpm, thereby diffentiating dir/file dependencies with stricter tests 
for, say, %ghost marked paths.

-- 
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/439#issuecomment-384799422___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Provide a way to opt out from automagic Python bytecompilation (#434)

[Jeff Johnson]

@Conan-Kudo: And "Who maintains RPM?"

Expecting C programmers to maintain a shell script to make Python packaging 
easy and uniform in several distro's is an exercise in politics, not 
engineering.

Handing the script to either Python programmers or distro QA engineers is far 
likelier to get timely fixes then in an upstream rpm release.


-- 
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/pull/434#issuecomment-385587315___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

[Jeff Johnson]

@jasontibbitts: apologies if you have interpreted "serious" as a criticism of 
your personal efforts
That wan not my intent.

Meanwhile, your suggested patch -- the only positive suggestion of what you 
wish -- is little more than force loading a number of modules based on globbed 
names, regardless of usefulness (to rpm embedding of lua), total ignoring the 
support within the lua language to load modules (either scripts or C level 
bindings) through LPATH/CPATH, including envvar overrides. Otherwise, your 
patch would be a vital first step to changing how rpm+lua functions: meanwhile 
prior art exist, using what is implemented in lua-5.x since 2003. Just ... why 
reinvent round wheels imperfectly?!?

(aside)
I claimed no "serious" attempt to use rpm+lua since 2003. That is in fact not 
true: there is an entire *nix distribution that chose to use rpm+lua embedding 
in order to create a distribution, which "worked" but alas, not rpm4.org code. 
Meanwhile, I will quote the person who used rpm+lua to do that distribution
* "If rpm had embedded perl instead of lua, I would not have used rpm+lua".
I'm sure you can find the distribution that I refer to.

Now for other interpretations of "serious"
* there have been no attempts to patch init.lua until your RFE (that I am aware 
of). You are welcome to examine the last ~15y of rpm releases to ascertain the 
objective truth of my claim.
* using patterns to force load modules -- while well intended -- ignores 
changes to support LPATH/CPATH requires(foo) loading that are now part of lua 
(for at least 4y now, albeit lua has abandoned at least one module loading 
scheme since 2003).
* force loading modules (as in your patch) forces another lua layer to 
"require" whatever modules rpm deems useful. There is no well defined way to 
track module existence within rpm dependencies, particularly when (as likely) 
lua is being used in %pretrans scripts. Specifically: what is rpm to do when, 
say, some module is unavailable in an *empty* tree after chroot(2) has been 
performed? Returning an error is not a satisfying answer imho.

A "serious" implementation for rpm+lua embedding with init.lua has (at a 
minimum, imho) MUST attempt to deal with chroot(2) path prefixes on *empty* 
chroot's using (if up to me) mount -bind calls to map trees from the host into 
the hosted chroot tree. YMMV.




-- 
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/321#issuecomment-340133804___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: give some freshness to brp scripts (#308)

[Jeff Johnson]

@Conan-Kudo There is nothing stopping

3: add script to SourceN: and invoke as %SOURCEn

4) change the macros that specify what scripts to run (but that is what is 
being claimed "clunky" when in fact what is desired of rpm is lazy DWIM)


-- 
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/308#issuecomment-355627132___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Fix sigheader generation for big archives (#379)

[Jeff Johnson]

headerSizeof() is expensive: you are better off doing more careful arithmetic.

-- 
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/pull/379#issuecomment-355623506___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: give some freshness to brp scripts (#308)

[Jeff Johnson]

@Conan-Kudo: Providing an additional directory where brp scripts might be found 
doesn't address conditionalizing which brp scripts are run dynamically.

Its rather easy to add Yet Another Directory of brp scripts (augmenting PATH), 
but its rather harder to determine which scripts to run.

There are two choices to conditionalize running brp scripts based on package 
content:

1) write the brp script to do nothing if condition is not met and run always.

2) add a build requires and invoke the script at the end of %install explicitly




-- 
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/308#issuecomment-355625771___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: '!=' vercmp operator (#376)

[Jeff Johnson]

FWIW, there are no negated dependencies at all in RPM4. E.g. Requires: !foo == 
bar being rendered as Conflicts: foo == bar (with similar for other operators).

-- 
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/376#issuecomment-355362389___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: '!=' vercmp operator (#376)

[Jeff Johnson]

Use Conflicts: with ==.

-- 
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/376#issuecomment-355361870___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

There's several ways to solve a renaming: pick you poison wrto your packaging 
policy.

Add a Provides: for the F26 name to the F27 package (or vide versa).

You can also add a file dependency, or add a Newer! Better! Besetest! name to 
both packages/modules.

-- 
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/373#issuecomment-353537729___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

@AdamWill so there is the problem of what I would call dueling package 
managers, and it's unclear (particularly because of ever changing 
incompatibilities in python) what solution(s) should be pursued by rpm.

By all means, use pypi (or apt or ...) if that is what one wishes. Blaming rpm 
for incompatibilities without making positive (reversion of "rpm" to 
"rpm-devel" is hardly positive, rather a flip-flop-flip random walk imho) 
suggestions of what behaviors are desired leads no place useful (to rpm).

-- 
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/373#issuecomment-353700354___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

Truly rpm-python should be split off to its own project in the eco system, 
published to pypi, and whatever else is desired, rather than blaming rpm 
developers for Newer! Better! Bestest! Python (and depsolvers) changes.

That was the original plan back in 2006 or so, just no round 'tuits.

RPM itself has zero use of Python bindings, and that isn't likely to change any 
time soon.

-- 
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/373#issuecomment-353700952___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

Correction: PEP 345 appears to have a Provides-Dist: tag to handle virtual 
packages bundled together. Using existing functionality wisely (assuming 
implemented) would seem to be the best way forward.

Providing two egg-info files to handle the change seems rather hacks.

-- 
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/373#issuecomment-353701818___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

If the name isn't used (what I called "informative"), then there should be no 
difference in loading behavior (unless there is some silly (imho) check on 
metadata consistency, in which case 2 egg-info files is the only way to deal 
with what has already been released).

The actual failure mode would provide hints to dig into sources: without the 
explicit error texts, I can only guess,

-- 
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/373#issuecomment-353698529___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

The key issue here is "What is the failure mode?".

If setup tools is constructing module paths from egg-info Name: directives 
(which is rather deficient) then there is no solution available (AFAICT) except 
to feed a Name: directive in some alternative egg-info file.

If Name: is purely informative, then something like a symlink within 
site-packages might be a sufficient finesse.

Without installing & running Fedora and using strike, its hard to differentiate 
which of this solutions might "fix" your problem.

BTW, you also need to differentiate between python models (which can be 
sub-classed), and C=modules like rpm-python (which are sub-typed, not 
sub-classed).

-- 
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/373#issuecomment-353697703___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

FWIW, rpm permits virtual package names, where a Provides: is treated 
identically to a package NEVR. This was deliberately (and incompletely) ripped 
out of Obsoletes: 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/373#issuecomment-353700046___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

[Jeff Johnson]

@AdamWill I fail to see how 2 names is better than one, particularly since 
there seems to be no already implemented mechanism within egg-info to deal with 
multiple names (and the claim afaict is that the functionality is deemed 
unnecessary).

-- 
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/373#issuecomment-353701142___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Track and log failures when loading macro files (f7aff11)

[Jeff Johnson]

For extra credit: The line number (and the current type of definition like 
RMIL_MACROFILES) might reasonably be attached to each macro definition, perhaps 
by masking to avoid changing rpmDefine() in the API.

 Otherwise add additional int arguments to rpmDefine()

-- 
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/commit/f7aff1193e7a27b631030f332ecfe87046853903#commitcomment-26743516___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Disable redefinition or undefinition of a built-in macro (9343ecd)

[Jeff Johnson]

If you are going to add a hard wired validation table for builtin macros, then 
you might as well use the same table for dispatching during macro expansion.

Possibly better would be to add a builtin flag to defined macros and treat as 
all other macros are treated, thereby permitting builtin macros to be 
redefined. 

-- 
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/commit/9343ecd94cd873e6dc1c06428975163cbb9cf9af#commitcomment-26744046___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Track and log failures when loading macro files (f7aff11)

[Jeff Johnson]

Abusing the negative level macro definition as an index into files from which 
definitions were read, with an associated file name table, as well as the 
modest change to display the file name(s) where macros are defined, is likely 
more useful than detecting errors while loading/defining a macro.

There really aren't too many useful syntax failures loading/defining macros: 
the harder task is locating where a macro is/was defined.

-- 
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/commit/f7aff1193e7a27b631030f332ecfe87046853903#commitcomment-26743058___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Checks for Obsoletes (#385)

[Jeff Johnson]

Nagware to effect policy is usually just an annoyance.

There are arguable cases (in renaming) where versionless or greater than are 
perfectly sensible.

Also: Obsoletes: (after installation) are essentially Conflicts: and should be 
treated similarly if you insist on adding nagware.

-- 
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/pull/385#issuecomment-360913970___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Add an API for libsolv, libdnf, et al to use to check if rpmdb has changed and trivially get path to rpmdb (#388)

[Jeff Johnson]

Presumably the desired rpm API is some Boolean valued function that returns the 
value "changed" with minimal hassle.

What isn't clear is what changed means: time stamp since ... ? package count 
has changed since ... ? digest on files composing an rpmdb?

There is certainly existing prior art in yum detecting rpmdb changes (though 
it's unclear whether yum knows about anything but BDB). There are also 
nitpicking details (like w yum) about what "changed" means that need to be 
defined. E.g. yum complains if an rpmdb is changed by a manual rpm command.

Since the predominant paradigm of depsolvers like DNF/libsolv is to strip all 
rpmdb info initially and then run a install/upgrade/erase transaction (with 
implicit rpmdb changes under exclusive write lock), it's unclear (to me 
anyways) how an API would be used.

Detecting paths to multiple back ends based on macros isn't that difficult. 
Harder is the problem of, say, having multiple co-existing back ends: which 
back end should be used to compute "changed"?
Shoukd a back end switch, or a --rebuilddb, constitute a "change"?

There is the further problem of keeping time stamps across --rebuilddb to 
prevent backup software based on time stamps from needlessly backing up rpmdb's

All solvable problems, just not sure whether an API is all that useful.

-- 
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/388#issuecomment-362717768___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Add an API for libsolv, libdnf, et al to use to check if rpmdb has changed and trivially get path to rpmdb (#388)

[Jeff Johnson]

Presumably the desired rpm API is some Boolean valued function that returns the 
value "changed" with minimal hassle.

What isn't clear is what changed means: time stamp since ... ? package count 
has changed since ... ? digest on files composing an rpmdb?

There is certainly existing prior art in yum detecting rpmdb changes (though 
it's unclear whether yum knows about anything but BDB). There are also 
nitpicking details (like w yum) about what "changed" means that need to be 
defined. E.g. yum complains if an rpmdb is changed by a manual rpm command.

Since the predominant paradigm of depsolvers like DNF/libsolv is to strip all 
rpmdb info initially and then run a install/upgrade/erase transaction (with 
implicit rpmdb changes under exclusive write lock), it's unclear (to me 
anyways) how an API would be used.

Detecting paths to multiple back ends based on macros isn't that difficult. 
Harder is the problem of, say, having multiple co-existing back ends: which 
back end should be used to compute "changed"?
Shoukd a back end switch, or a --rebuilddb, constitute a "change"?

There is the further problem of keeping time stamps across --rebuilddb to 
prevent backup software based on time stamps from needlessly backing up rpmdb's

All solvable problems, just not sure whether an API is all that useful.

-- 
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/388#issuecomment-362717773___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Moving from rpm-3.0.X to latest version 4.13.0.2 (#384)

[Jeff Johnson]

Yes, db1 is no longer supported in rpm (for like the last 15y).

Meanwhile -- if you _REALLY_ insist on rpm database compatibility -- you could 
possibly do the conversion by installing several (perhaps 3, possibly 2) 
versions of rpm and doing rpm --rebuilddb.

You would be in for some serious backporting efforts to assemble the needed rpm 
versions on a single platform however. Its likely easier to just upgrade the 
operating system and rebuild all packages needed.

-- 
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/384#issuecomment-361108228___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement wrapper for posix.fork()+posix.exec() (#389)

[Jeff Johnson]

@ignatenkobrain: Um not, implements, but embeds.

lposix.c was a concatenation of the lua posix module available at the time.

Note the "posix." name spacing. 

Perhaps it's time to upgrade the lua posix module and eliminate bloat?

-- 
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/389#issuecomment-363508103___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

[Jeff Johnson]

If you are going to sign "mutable" %config files, you might as well sign %ghost 
files as well (by signing the hash of the null string).

-- 
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/pull/374#issuecomment-364566830___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

[Jeff Johnson]

One might well ask: Why sign any "mutable" file?

The (rather inchoate) answer supplied in the original RFE for signing %config 
files is (iiuc) was 1) so that IMA policy can be written against %config files 
and 2) so that %config files in a package will have an ima signature in an 
xattr.

The same reasoning applies to %ghost files which are "owned" (with usual 
perms/uid/gid metadata) by a package. The content of %ghost files is usually 
generated in %buildroot using touch(1), so the appropriate signature for %ghost 
files would be a signature on an empty (but "mutable") file.

The main reason for treating %ghost like empty %config files is to remove 
special cases peculiar to rpm packaging that show up later as RFE's.



-- 
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/pull/374#issuecomment-364620067___
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 query causes corruption in the file-backed mmaped bdb regions (#232)

[Jeff Johnson]

@pmatilai: yup, DB_RECOVER requires configuring Berkeley DB when opening 
correctly in order to use.

Hint: execing dbXY_recover on an idle database (already protected by an 
exclusive write lock) fixes stale locks. Performing that operation when needed, 
not every 15 minutes with a Facebook fork bomb, seems like a saner approach.

-- 
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/232#issuecomment-365353871___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

[Jeff Johnson]

Yes --replacefiles just sets a transaction flag bit (equivalent to ".*" but 
there are no patterns involved).

By "disable", I mean build all packages without %config or %ghost, avoiding the 
need for special handling, and simplifying ima appraisals on embedded devices 
(the example given in #364).

Truly, the %config path renaming in rpm makes little sense on vendor managed 
embedded devices using ima signatures. Just don't use %config, treat all files 
the same, and write your ima appraisal policies to avoid mutable files (which 
you will have to do anyways to handle the RFE in #364).

-- 
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/pull/374#issuecomment-364814623___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

[Jeff Johnson]

@nim-nim: "... define the best dynamic BR strategy over time" is *EXACTLY* the 
chicken-egg problem mentioned by @ffesti. Think a bit ...

-- 
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/104#issuecomment-364815788___
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 query causes corruption in the file-backed mmaped bdb regions (#232)

[Jeff Johnson]

@jayzmh: the issue with dcrpm is the costly detection and possibly imperfect 
analysis of "bad actors" not how often db_recover is run. dcrpm is treating a 
symptom rather than solving the root cause of whatever problem exists.



-- 
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/232#issuecomment-365599296___
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 query causes corruption in the file-backed mmaped bdb regions (#232)

[Jeff Johnson]

Um, *this* issue is about RPM behavior on OS X and a sandbox policy prohibiting 
writes.

Open an issue with details with details about your Facebook problems if you 
wish.

The output of db_stat showing the state of locks is usually the starting point 
to identifying the root cause.

-- 
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/232#issuecomment-365698899___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

[Jeff Johnson]

FYI: MaximumRPM was written in 1997 and does not begin to define the necessary 
semantics to implement signatures on mutable files in a useful way. There have 
been several changes in both %config/%ghost handling since 1997.

Q: What use is it to IMA policies to have a pre-packaged signature on a file 
that has been marked %config?

The original RFE pretended to a type of configuration that is inaccessible to a 
user on a embedded/handheld device that could not (or should not) be changed. 
In which case, using %config is a packaging error imho and can be handled 
through the existing file signing mechanisms.

The original RFP (and your comment) indicates that indeed, signing mutated 
files has obvious failure cases, which is ultimately a 2nd type of "really 
mutatable" %config, different from the packaging error misuse/abuse of %config 
on a file that a user could not (or should not) change.

Finally there are several comments -- including mine -- that indicate that the 
ability to sign "mutable" %config files does not seem very useful, and hence 
needs a disabler with opt-in default behavior.

(aside)
Adding the ability to change the ima signature in the xattr after installation, 
so that the modified, not the original %config template, would (at least) 
change my opinion, similarly for %ghost. But that isn't what is being proposed.

-- 
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/pull/374#issuecomment-364628202___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

[Jeff Johnson]

There is also the run-time variant of the previous build-time configuration: 
use a macro to define a mask that is applied to rpmfiFFlags() return value 
before testing for RPMFILE_CONFIG.

A global per-system (or per-transaction) AND mask (defaulted to 0x) 
could be generally useful in RPM.

Ideally, a per-file override of an inherited per-transaction AND mask would 
provide the ability to disable RPMFILE_CONFIG on a per-file basis.

-- 
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/pull/374#issuecomment-364630577___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

[Jeff Johnson]

There is a very simple macro
%define %config %{nil}
which -- when added to rpmbuild configuration -- achieves an ima signature on 
every file without any fuss whatsoever.

-- 
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/pull/374#issuecomment-364628947___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Request to apply IMA signatures to files even if deemed a configuration file (#364)

[Jeff Johnson]

I have read #364, the basis of which is a belief that security policies like 
ima should be set by the end user, not the packager.

An imperfect implementation in rpm to generate ima signatures that are invalid 
when %config files are altered seems a pointless mechanism to generate useless 
false positives.


-- 
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/364#issuecomment-364659266___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Request to apply IMA signatures to files even if deemed a configuration file (#364)

[Jeff Johnson]

I have read #364, the basis of which is a belief that security policies like 
ima should be set by the end user, not the packager.

An imperfect implementation in rpm to generate ima signatures that are invalid 
when %config files are altered seems a pointless mechanism to generate useless 
false positives.


-- 
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/364#issuecomment-364659263___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement wrapper for posix.fork()+posix.exec() (#389)

[Jeff Johnson]

These are RFE's for the lua posix module (and should be implemented/patched 
there), not for RPM.

-- 
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/389#issuecomment-363419762___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

[Jeff Johnson]

If -- as this RFE seems to assume -- you are going to limit the implementation 
to "... (Rust, Python, golang) ..." that have alternative non-specfile means to 
specify BuildRequires, then all known rpm build systems will require a change 
to augment the installed files with newly discovered "dynamic" BuildRequires.

Repopulating a buildroot with additional "dynamic" BuildRequires and restarting 
an rpm build either needs to teach rpm how to install additional packages as a 
side effect of parsing, or needs to be handled by depsolvers that populate the 
buildroot (entirely out of scope for the current rpmbuild implementation) 
before rpmbuild is invoked.


-- 
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/104#issuecomment-366421642___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

[Jeff Johnson]

Contrarian examples are trivial to devise. Consider an autoconf based generated 
file that builds if (and only if) certain files are detected. None of those 
BuildRequires can be automated and generated during a spec file parse with a 
pipe/file redirection.

The only solution (I can see) is an attempted build on a system with 
"everything" installed that then repeats with the BuildRequires: detected from 
the "everything" build.

There is currently no known way other than "works" to verify that the 
BuildRequires passed to the depsolvers that populates the build system used. 
Only looping to test that the BuidRequires are sufficient.

Hence any attempt to automate BuilRequires *MUST* have a persistent incremental 
store from which the automagically generated BuildRequires can be retrieved on 
the final build.

-- 
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/104#issuecomment-366420520___
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 query causes corruption in the file-backed mmaped bdb regions (#232)

[Jeff Johnson]

Guesses are worthless, particularly when you haven't the time to identify your 
problem.

-- 
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/232#issuecomment-365915864___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement fast mode for getting EVR (#392)

[Jeff Johnson]

Then you are stuck: it's your workload, not the rpmspec parser implementation, 
that is the root cause.

-- 
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/392#issuecomment-366440232___
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_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

[Jeff Johnson]

(from memory)
I think I fixed this problem 4-5 years ago in RPM5 (like rpm-5.4.15? I forget).

The MD5 tag length (and RPM_BIN_TYPE in general) includes padding (if present) 
to the next tag.

The bug only shows up if the next tag needs to be aligned.

The real fix wasn't hard, but was rather subtle and surprising.

The proposed fix special casing the MD5 tag is deficient because it ignores 
legacy compatibility: nearly all versions of rpm this century are affected.

Mark Hatle (from Poky/Yocto) likely can supply the actual patch I checked into 
RPM5. I was somewhat surprised at the time that the bug had never been reported 
against RPM4 with identical code.

-- 
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/398#issuecomment-366710446___
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_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

[Jeff Johnson]

Good: identical problem accessing RPM_BIN_TYPE "drips" (i.e. signature tags 
appended to an immutable region).

The problem is in the API access, not in the format, so no painful hacky 
retrofit will be needed.

It sure would be nice to see the 1-line fix pushed back through "supported" 
platforms to prevent waiting another 4-5 years for the next bug report.

-- 
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/398#issuecomment-367794187___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpmio.c: In Fread(buf, size, nmemb, FD), require size be 1 (#400)

[Jeff Johnson]

FWIW, you idiomatic code *never* worked with unmatched RPM4 sources including 
rpm-4.0

-- 
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/pull/400#issuecomment-368150719___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpmio.c: In Fread(buf, size, nmemb, FD), require size be 1 (#400)

[Jeff Johnson]

Yes, the "clone" of fread/write is imperfect and always returns the no. of 
bytes rather than nitems.

The flaw certainly hasn't stopped Fread/Fwrite from being both used and useful 
everywhere in rpm this century.

There's more needed than just your patch.

FYI: RPM5 rpmio returns nitems just as the posix stdio routines do GeForce the 
last couple years.

-- 
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/pull/400#issuecomment-368149370___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Should python(abi) be provided by the interpreter or something else? (#395)

[Jeff Johnson]

The python(abi) requirement was originally invented to associate a *.py script 
in a package with an interpreter package. Most of the Requires: are 
automatically generated from *.py files (which ultimately determines how the 
Provides: should be added).

Detailed dependency semantics involving embedded interpreters and libraries and 
interpreter sub-packaging are largely ad hoc and de facto, so there really 
isn't any right or wrong, only what "works".

-- 
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/395#issuecomment-366030170___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] lua: add rpm.execute() (#390)

[Jeff Johnson]

The real flaw with looping over close(fdno) before exec in rpm is that it masks 
the root cause of the problem: applications that are not setting FD_CLOEXEC.

The loop also prevents an application from intentionally passing an open fdno 
to a child of rpm (if that is/was intended).

I'd suggest removing the loop entirely (or logging leaky fdnos) so that 
applications can be fixed directly: it's not a difficult patch in most cases.

-- 
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/pull/390#issuecomment-367384963___
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_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

[Jeff Johnson]

(I'm sure you know this) NEVRA isn't unique even if commonly used, and pkgid is 
the only candidate for a unique id available for almost all *.rpm packages ever 
built without painful retrofits. The SHA1  hdrid is likelier to be noticed 
sooner because it maps directly into "what git does"' but a UUID representation 
permits choice of a identifier that can be implemented without enormous 
discussions.

It's not the count field in the package file, but rather the value returned 
through the API that goes awry.

-- 
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/398#issuecomment-367380315___
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_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

[Jeff Johnson]

@pmatilai: au contraire, the MD5 of the original package is the only 
"universal" (in the sense of being present all the way back to RPM2) 
precomputed  identifier for a *.rpm package if/when converted to a UUIDv3 (see 
the query format issue) to be (eventually) used as a database key rather than a 
cryptographic verification.

IIUC, you might want to check the MD5 tag count when retrieved from the 
signature header before being appended to the metadata header stored in an 
rpmdb. The root cause and best fix may be earlier in the retrieval.

The RPM5 issue was quite obscure, is/was triggered by padding in a signature 
header when mandatory  elliptic curve signatures were added, changing the tag 
content of a signature header. I'll dig out the one line change when I get a 
chance.



-- 
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/398#issuecomment-366998156___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint