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
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
> 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
> 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
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
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
