[arch-projects] [namcap] [PATCH 0/4] Add a rule against common filenames in source() without overridden name
There's no good way for namcap to ensure source() filenames are unique across all packages, required for users with SRCDEST. But, I think by far the most common offending filename would be LICENSE, as non-standard ones are required to be included, but sometimes there's no upstream tarball or there is but it's not in there. Mostly an issue for AUR packages, but maybe there are official ones violating this too. We can at least check that if common names are in source(), they're given an overridden name. (Personally, I'm going with "${pkgname}-LICENSE::", but this patch doesn't force this form.) While adding this, split off the recently added non-unique versioned source filenames (non-overridden versioned tarballs) from pkginfo rules. This was originally there using PkgInfoRule, but when it was switched to PkgbuildRule, it was left in pkginfo.py. Also add tests for the recently added non-unique versioned source filenames rule.
On 5/26/19 10:35 PM, James Harvey via arch-projects wrote:
There's no good way for namcap to ensure source() filenames are unique across all packages, required for users with SRCDEST. But, I think by far the most common offending filename would be LICENSE, as non-standard ones are required to be included, but sometimes there's no upstream tarball or there is but it's not in there. Mostly an issue for AUR packages, but maybe there are official ones violating this too.
We can at least check that if common names are in source(), they're given an overridden name. (Personally, I'm going with "${pkgname}-LICENSE::", but this patch doesn't force this form.)
While adding this, split off the recently added non-unique versioned source filenames (non-overridden versioned tarballs) from pkginfo rules. This was originally there using PkgInfoRule, but when it was switched to PkgbuildRule, it was left in pkginfo.py.
Also add tests for the recently added non-unique versioned source filenames rule.
All your patches show up as attachments, which makes it difficult to review, and they don't show up in patchwork. Generally speaking, the most reliable way to send a patch is by using `git send-email`. -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, May 26, 2019 at 10:45 PM Eli Schwartz via arch-projects
All your patches show up as attachments, which makes it difficult to review, and they don't show up in patchwork.
Generally speaking, the most reliable way to send a patch is by using `git send-email`.
Sorry about that, I'll setup 'git send-email'. Was just talking on IRC because I saw they're scrubbed here: https://lists.archlinux.org/pipermail/arch-projects/2019-May/thread.html Should I re-send using 'git send-email' or leave as is?
participants (2)
-
Eli Schwartz
-
James Harvey