Summary: | Mk/Uses/zip.mk: Add switch for (bsd)tar | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Daniel Engberg <diizzy> | ||||
Component: | Ports Framework | Assignee: | Port Management Team <portmgr> | ||||
Status: | Closed Works As Intended | ||||||
Severity: | Affects Only Me | CC: | arrowd, bofh, ports-bugs | ||||
Priority: | --- | ||||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
What are use cases for this? It would be nice for consistency in cases like these: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278745 I've actually submitted a bunch of patches recently to reduce I/O for a bunch of ports, a rough estimate would be around 2-3Gbyte or so in total if applied. I mean, the port shouldn't really care if we're using bsdtar or not? Why have a special USES argument for this? It doesn't but its nice for consistency to be able to use the same syntax such as in EXTRACT_AFTER_ARGS irregardless of typo of archive whenever possible (I'm aware the some archives needs unzip/infozip). Another use-case, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278779 Can't we just automatically switch to bsdtar whenever possible inside zip.mk, without requiring a port to specify :bsdtar argument? If I understand it correctly, it is just a matter of testing OSVERSION or even .if exists() ? From what I recall it's a POLA issue as bsdtar doesn't share the same syntax as unzip and/or infozip? Friendly ping on how to proceed I don't think it is a good idea. The framework does not have to include every possible knob for every possible usage. You can already use bsdtar to extract a zip file, and you figured out how to do it by yourself, this is enough. |
Created attachment 250461 [details] Patch for Mk/Uses/zip.mk Teach zip helper about (bsd)tar for consistency and remove the need to define EXTRACT_SUFX