Note that we don't run db_recover unless we detect an issue. dcrpm works by
trying to detect common issues and issue the nicest possible recovery - from
db_recover to other finding held locks by bad actors to other things.
--
You are receiving this because you are subscribed to this thread.
@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
> DB_RECOVER requires DB_INIT_TXN, which is incompatible with DB_INIT_CDB that
> rpm.org still uses. And enabling TXN on BDB runs into all sorts of fun with
> BDB log file paths across chroots, requires additional infra in the code etc
> and whatnot. All solvable issues no doubt, but it piles
The reluctancy is to add features that end up entirely unused. Oh, and features
which don't really fit rpm design principles to begin with.
Personally, I'd *love* to see Fedora get rid of the changelogs maintained in
specs and happy to help with it from my behalf, but until somebody actually
Of course some distributions found their way despite RPM upstream being
reluctant to support this or similar feature. The #69 just proves that. I did
not mentioned Fedora anywhere and I don't think that #69 was proposed by Fedora
people.
--
You are receiving this because you are subscribed to
https://github.com/rpm-software-management/rpm/pull/69 is related and has some
relevant discussion of the caveats etc.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah there are any number of ways to do it. Multiple distros are doing it via
other tooling sitting on top of rpm, that's an entirely valid route and already
proven route. Other options include having rpm execute some hook to pull data
from an outside source into the spec (and yes putting that
On a related note... our fix-the-rpm-db program has been opensourced:
https://github.com/facebookincubator/dcrpm
We run it every 15 minutes as a pre-script to configuration management.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Well, one big advantage from the %include/%changelog way would be the possible
opt-in. If you want to automate "slapping the changelog itself at the tail of
the spec", then it means you have to actually change the build infrastructure
to do it.
TBH the biggest issue I see currently is that the
> I can also easily back port the core fix to the problem reported here,
> implemented years ago @rpm5.org:
>
> when DB_RUNRECOVERY is returned opening a BDB dbenv, then do the recovery
> by setting a flag, and repeating the open one time, thereby running recovery.
DB_RECOVER requires
Documentation says "for all installed packages that contained...", nowhere does
it say installed in *this* transaction.
The "obvious" reason(s) for the behavior is that when installing the package
containing the trigger, you want to get it to do its thing on the packages that
are already
> %transfiletriggerin: Executed once after transaction for all installed
> packages that contained file(s) that matches prefix of this trigger. Also
> executed after transaction if there was a package containing this file
> trigger in that transaction and there is/are some files(s) matching
Why would you run ldconfig (for example), if there was no library installed /
changed during transaction? Just to be sure?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> and installed package set
this doesn't make any sense for me...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #386.
--
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/386#event-1471178645___
Rpm-maint mailing list
Hmm, actually I don't think this is a bug afterall: file triggers match files
from the current transaction *and* installed package set, just like regular
triggers do. And prefix / happens to match all installed files. It'll seem more
sensible with a more reasonable prefix.
--
You are
Splitting spec into multiple pieces (whether %include or otherwise) tends to
have all sorts of downsides, especially because it breaks long-standing
expectations of specs being standalone entities. I'm not actually opposed to
adding %changelog -f but I'm also not convinved it's be best way to
17 matches
Mail list logo
