[aur-requests] [PRQ#18055] Deletion Request for uperm

Eli Schwartz eschwartz at archlinux.org
Mon Feb 24 04:23:27 UTC 2020


On 2/23/20 8:10 PM, Dmitri McGuckin wrote:
> Not that I care about the package itself but most of the criticisms laid
> out are subjective.
> 
> Nothing listed above is explicitly laid out in the guidelines for
> user-packages:
> https://wiki.archlinux.org/index.php/Unofficial_user_repositories#Adding_your_repository_to_this_page

You're looking at the wrong page, the AUR is governed by
https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_submission

> Unless I'm missing something, /opt is intended for user programs. If you
> have a better idea of where it should be, I'd love to hear it, but again,
> not inherently a valid reason for removal.

Incorrect, /opt is intended for things which are self-contained rather
than following the Filesystem Hierarchy Standard (i.e. they don't fit
neatly into bin/ include/ lib/ and share/ directories).

Shellscripts can and do get installed to /usr/bin all the time.

But, this is not the issue that I mentioned. The issue that I mentioned
is that the PKGBUILD will sudo install the file to /opt, and then
makepkg will create an empty package. You can pacman -S uperm or pacman
-R uperm and it doesn't make a difference, because the software consists
of untracked files copied to /opt before the package was created.

PKGBUILDs must install their files to "${pkgdir}/opt" or "${pkgdir}/usr"
and NOT to /opt or /usr ...

... or else they are not even a package in the first place.

See https://wiki.archlinux.org/index.php/Creating_packages#package()

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20200223/c2d225e0/attachment.sig>


More information about the aur-requests mailing list