if the problem is an empty file being queried, why not solve teh problem where
the action occurs (before the test), with something simple like:
[ -s $ARG ] && ...
I don't see that this is the rpm binary's issue
--
You are receiving this because you are subscribed to this thread.
Reply to
> Yes, right. Then you won't have any problem finding hundreds of packages
Under the present system, my tooling runs and provides sub-second look-ups on a
corpus of (today) 796479 packagings
Stop picking a fight
--
You are receiving this because you are subscribed to this thread.
Reply to
No 'quirks' at all ... I have built my tools with the rpm and rpmbuild man
pages open, and consulting:
rpm --showrc
That's how developing in an Unixy (tm) environment works
I know what is not a good idea on the Usenet ... ahh, times change so silly me,
having been the editor of RPM.ORG
> The probability anyone will create an archive containing a %{name}-%{version}
> topdir while not named %{name}-%{version} is vanishingly smal
My build tools do this 'different %_topdir naming' on ** every ** build
It might make sense to actually use rpmbuild for a decade or so before
As I understand the model for rpm-ostree, it assumes a Read Only, and
re-located RPMDB
Wouldn't a more general fix than the one seemingly already committed about
inability to calculate TS disk size requirements, be a simply attempt to
connect with the BDB and get a lockfile? this would
My archive of unpacked .spec file disputes @ignatenkobrain comment above --
backward compatibility matters
[herrold@centos-7 SPECS]$ grep "\%py" *spec | grep -v ":#" | wc
39 1461953
[herrold@centos-7 SPECS]$ grep "\%py" *spec | grep -v ":#"
BitTorrent.spec:%pyrequires_eq