Apologies for this not progressing anywhere, but the time in between has
confirmed that something like this will need a general purpose use-case in rpm
itself so that it can be regularly tested.
We'll be exploring this area in the future, but this isn't the time, we need to
focus on v6. I'm
Closed #2416.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416#event-12335589169
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Also we still need a way for the plugin to claim ownership of a package to
trigger the reflinking during install.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416#issuecomment-1598860857
You are receiving this because you are
Thanks for the valuable comments. I will look into creating the new FA_REFLINK
file action. For the transcoding part, if we unpack the package files in a
directory, I think we still need to keep the package header somewhere for rpm
to process it, but this could indeed be a good approach. I will
I don’t consider any sort of streaming unpacking to be viable with the v4 file
format. For it to be viable with v6, v6 would need to use some sort of Merkle
tree to allow incremental verification of the signature. One option would be
to pack a bunch of hashes (as binary, not hex) into a
The more I think about it, the more I think it has to be rpm that is
responsible for installing files. Delegating that to a plugin creates a support
nightmare where we (as an upstream) no longer have the slightest clue what
might be going on in case of problems, and requiring every bug report
@dmnks , FA_PLUGIN and FA_CUSTOM have effectively the same problem as previous
versions of this patch had with RPMRC_PLUGIN_CONTENTS: there could be multiple
plugins wanting to claim it, whereas there can only ever be exactly one thing
to create a file. See
> What if we instead had a FA_REFLINK file action (supported in rpm core), and
> the plugin would 1) set this for applicable files 2) supply the necessary
> details such as what to actually reflink to?
I like this idea. In the context of `rpmFileAction`, reflinking indeed can be
seen as a file
This is indeed closer to what I had in mind, but. It ends up leaking way way
too many rpm internals (fsm and all) to the plugins - plugins which need to get
by with just public rpm APIs. (This may have been an issue with the earlier
versions as well, I don't remember or maybe I never got that
@pmatilai @DemiMarie Did you get a chance to have a look at this?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416#issuecomment-1479478779
You are receiving this because you are subscribed to this thread.
Message ID:
@rphibel pushed 1 commit.
8a7cd8139b759d1711273839a6502333e3c0f914 Create content handler plugin hook
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416/files/5965d2be5b80eea738b767a5b48c5bff50c87da3..8a7cd8139b759d1711273839a6502333e3c0f914
You are receiving this
@rphibel pushed 1 commit.
5965d2be5b80eea738b767a5b48c5bff50c87da3 Create content handler plugin hook
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416/files/82b6cfe2cfdc981cc7fcda4ecd473c8729aa6920..5965d2be5b80eea738b767a5b48c5bff50c87da3
You are receiving this
### Description
This change creates a new `content_handler` plugin hook. This hook can be used
by plugins to claim responsability for the package payload. The plugin will
then be responsible for:
- reading the payload
- verifying it
- installing the files
The main motivation for this change is
13 matches
Mail list logo
