[Rpm-maint] [rpm-software-management/rpm] RPM v6 package generation rough-cut (PR #2920)

[Daniel Alley]

@dralley commented on this pull request.



>      headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
     headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
     headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
     headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
     pld = _free(pld);
 
+    if (pkg->rpmver >= 6) {
+	headerDel(pkg->header, RPMTAG_PAYLOADSIZE);
+	headerPutUint64(pkg->header, RPMTAG_PAYLOADSIZE, &payloadSize, 1);
+	headerDel(pkg->header, RPMTAG_PAYLOADSIZEALT);
+	headerPutUint64(pkg->header, RPMTAG_PAYLOADSIZEALT, &archiveSize, 1);

I'm not fully sure I understand the use case for this

`RPMTAG_SIZE` / `RPMTAG_LONGSIZE` already covers the "how much space does this package require once installed" case.  

`RPMTAG_ARCHIVESIZE` / `RPMTAG_LONGARCHIVESIZE` already covers the uncompressed payload size (in theory it should be the same as `RPMTAG_PAYLOADSIZEALT`?), and it's *supposed* to be in the main header.  And I don't think the value overlaps?  Why introduce something new, except to make the name more consistent?

There's no equivalent for compressed payload size, but with either compressed *or* uncompressed payload size, you can't really usefully extract the freestanding archive from the RPM, because RPM is (now) the only tool that can process that archive.  It just seems unnecessary to even include that info.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2920#pullrequestreview-1894488539
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2920/review/1894488539 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240221/b3170716/attachment-0001.html>