interesting hack. Would be nice if rpm could do that natively indeed. Would
help a lot to build git head of software based on the spec file of a stable
version. Might actually be doable by breaking the loop in
`processBinaryFiles()` into a two stage process.
--
Reply to this email directly or
I am trying to use file triggers to perform actions when a kernel gets
installed. Ie copy the kernel into the ESP and create boot entries. It could
happen that the ESP runs out of space. In that case the system would not boot.
In a traditional system one would be doomed anyway. In a
> The file order in payload doesn't match the one in the header, at least for
> hardlinks and other stuff that may not have content at all. Maybe in a
> perfect world one could expect that order to be strictly defined and always
> correct, but there are multiple cases in rpm history where one
Is there an actual need to have any extra headers in the payload? The payload
could be just raw file content. https://github.com/lnussel/rpm2extents does
that in a page aligned way but could also be back-to-back and compressed of
course.
--
Reply to this email directly or view it on GitHub:
In openSUSE the `user()` and `group()` provides are generated automatically if
a packages has systemd sysuser files:
https://build.opensuse.org/package/view_file/openSUSE:Factory/sysuser-tools/sysusers.prov
When sources of a package as well as the spec file are in git
([example](https://github.com/openSUSE/aaa_base/)), the `--build-in-place`
option for `rpmbuild` is quite convenient to build the package directly from
the checkout directory. How does one know whether a spec file is meant for
ould allow to have /usr read-only while
still being able to install 3rd party add-ons in separate locations.
cu
Ludwig
[1] https://lnussel.github.io/2020/12/16/fslayout/
[2] File flags (eg skipped files due to --excludedocs) are computed and
stored on installation time. Would have to think h
Hi! Great to see someone thinking about how to leverage CoW file system
features for RPM :-) I had some ideas on the topic a while ago too, coming from
a different direction. Thought about making the build system produce (and sign)
uncompressed rpms directly
zypper calls the rpm command. So a new transaction for each package..
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
s/zypper/zypp/
--
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/1370#issuecomment-701263659___
Rpm-maint mailing list
zypp installs rpms individually and disables transaction scripts:
https://bugzilla.suse.com/show_bug.cgi?id=1041742
If a script knew why it was called it could probably decide to ignore the
"useless" calls. Like eg by passing more arguments. Legacy scripts would not
use them and continue to
Trying to implement file triggers for mandoc to register and unregister man
pages in the whatis database I ran into some strange behavior. Note I can't use
transfiletrigger as zypp doesn't support that :(
- triggers are executed several times on upgrade and uninstall for the same
package (ie
There are efforts to get rid of distro default config files in /etc in favor of
built in defaults or files in eg /usr/etc. Means rpms no longer install stuff
into /etc. The transition there however requires some handling of existing
files in /etc. Unmodified ones should get removed while
> How do you detect a binary that will want to load some specific translations?
> Is it just some guess or should be up to packager to fill in or?
FWIW in openSUSE many packages have a "-lang" subpackage to contain all
translations. Those packages in turn have automated provides that translate
rpmdb --exportdb calls rpmtxnBegin() with RPMTXN_READ flags. Internally that
function calls rpmlockNew() and rpmlockAcquire(). Neither function has a flags
parameter to specify what kind of lock is requested. rpmlockNew() automatically
creates a read lock if it can't open the .rpm.lock file in
that's a good start at least. There's also --importdb. So with slightly more
code that could sync back and forth with a directory
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Note that installing the headers on disk as part of package installation does
not exclude actually using one of the existing database formats.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> * People can and will randomly manipulate files to force the package
> manager to do weird things (it's even documented in various troubleshooting
> guides)
Well, obfuscating the database for the purpose of avoiding people to mess with
it doesn't sound like an overly good motivation. RPM
With uncompressed payload one could even copy the full rpm into
/usr/lib/sysimage/rpm/installed and reflink the data.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
How about not storing rpm headers in some binary database anymore but rather as
individual files on disk?
Ie rather than stuffing them into /usr/lib/sysimage/rpm/Packages.$format just
dump them as is, eg
/usr/lib/sysimage/rpm/installed/hello-1.2-3.x86_64.rpm
That opens several possibilities
-
Maybe a provides generator could be used that parses sysusers files to avoid
any extra tags the packager has to put in spec files. Then a new kind of
trigger that acts on such provides could create the actual user.
--
You are receiving this because you are subscribed to this thread.
Reply to
21 matches
Mail list logo
