Add optional filelists_ext metadata#316
Add optional filelists_ext metadata#316kontura merged 1 commit intorpm-software-management:masterfrom
Conversation
|
There are some bits missing, mostly tests, some adjustments in the Python bindings, and all the sqlite code. But I want to present this patch as early as possible, to see if the approach will be OK |
|
The name "--hash" is somewhat confusing. Rpm calls those "digest", so why not --digest? And why is the filename "filelists_ext" if the option is called "hash"? Shouldn't it be "filehashes" or "filedigests"? |
|
No testcases? |
The first comment point other missing bits too. The patch was getting big without any review, so I decided to publish the code to have the chance of fixing issues before too long. Tests and SQLIte schema change will be added in this PR before removing the draft flag. |
Sure,
I think I will go for |
Done. I renamed it to |
1f5504c to
11c274c
Compare
|
Given that the |
I like the idea. The parser state machine is shared, I will see how I can unify the API. I must admit that when I do not understand the code, I make an explicit copy for the filelists_ext version. |
b875d3f to
8d9db76
Compare
Ok, I think that I know how to do this, thanks for the idea as it will remove a lot of issues. |
a59da74 to
34762c5
Compare
|
I still plan to add some tests, but I am thinking to drop the changes in sqlite for now. Meanwhile I moved the PR to ready for reviews. |
8506aad to
e6bad40
Compare
|
I updated some tests, and I decided not to break the cr_PackageFiles Python tuple, and not include the digest there. IMHO I am done. |
Yes, what I've now realized is that .sqlite metadata is de-facto deprecated even though it's still provided in most repos. None of the tools that consume it are mainstream anymore, except for legacy I filed this issue to turn it off in a future Fedora release. https://pagure.io/releng/issue/10745 So no changes to the sqlite metadata is likely preferable. |
| } | ||
|
|
||
| if (filelists_ext && entry->digest && entry->digest[0] != '\0') { | ||
| cr_xmlNewProp(file_node, BAD_CAST "hash", BAD_CAST entry->digest); |
There was a problem hiding this comment.
This probably should have an attribute to distinguish the digest algorithm used alongside the digest itself.
There was a problem hiding this comment.
There is a new XML field for each package, that indicate the algorithm (<checksum/>), this tag is the file digest itself
| cr_Package *package = NULL; | ||
|
|
||
| cr_PkgIterator *pkg_iterator = cr_PkgIterator_new( | ||
| TEST_REPO_04_PRIMARY, TEST_REPO_04_FILELISTS_EXT, TEST_REPO_04_OTHER, NULL, NULL, NULL, NULL, &tmp_err); |
There was a problem hiding this comment.
My understanding of this API then, is that if you want the full metadata, you substitute the path to filelists_ext.xml instead of filelists.xml?
There was a problem hiding this comment.
For the parser, this is the idea.
|
@aplanas Are you still interested in this? It needs rebasing... |
|
@Conan-Kudo Yes. Rebased! Is there anything actionable that I can do to bootstrap the discussion? Is the goal of this PR clear? Maybe there is a better way to connect the signature of the entity that create the repository with the value of the hashes? |
b3e6d79 to
a347d6a
Compare
|
@Conan-Kudo ping. Can you remove the "decaying" tag? |
kontura
left a comment
There was a problem hiding this comment.
Hello, sorry for the delay.
Unless I am wrong this breaks API only with the two functions I annotated, please can you rather create new ones? (the Python API should be fine as the new params are optional).
Otherwise in my opinion this is good to go and I would merge it.
Using the parameter '--filelists_ext', a new metadata file (filelists_ext) will be created. This new metadata is a copy of filelists, but will include a new attribute for the 'file' element, named 'hash', that contain the registered hash (SHA256 for example) for this file. Fix rpm-software-management#313 Signed-off-by: Alberto Planas <[email protected]>
|
Another option instead to duplicate similar functions, can be to drop --filelist_ext and generate it always, and is the user who decides to ignore it or not |
|
You probably don't need to "duplicate" per se, just have one implementation with a different signature which is called by the existing function, which would be turned into just a stub. |
Right, I used this approach. |
Using the parameter '--filelists_ext', a new metadata file
(filelists_ext) will be created. This new metadata is a copy of
filelists, but will include a new attribute for the 'file' element,
named 'hash', that contain the registered hash (SHA256 for example)
for this file.
Fix #313
Signed-off-by: Alberto Planas [email protected]