Post by Brett Cornwall via aur-generalI am being sponsored by dvzrv.
I've been working in the AUR since 2014 as 'Ainola'.
Hi Brett,
some small questions and hints first:
It looks like several packages have different issues preventing to build
in clean chrooted environments properly. Did you take a look at the
devtools package and building packages in clean chroots so far?
What software/tool do you using to track all the new ustream releases?
You still seem to use `mksrcinfo` for generating SRCINFO files, it was
deprecated in favor of native `makepkg --printsrcinfo` you may want to
use that in the future.
I have noticed that mostly all git packages lack sufficient
provides/conflicts on the basic non-git name schema and/or makedepends
on git itself, would be nice to keep in mind
Also i notices there are multiple packages that store a tarball in the
AUR source repo that contain things like icons, please don't miss-use
the AUR as a storage for tarball artifacts.
some findings after reading your PKGBUILDS, can you please take a look
and process the following feedback:
ags
- upstream Makefile doesn't seem to respect CPPFLAGS try to either get a
patch upstream or if that fails extend CFLAGS with CPPFLAGS in
the PKGBUILD.
creeper-world
- upstream source/url provides a https endpoint
- you can't reference the PKGBUILD like in prepare(), try building in a
clean chroot via extra-x86_64-build
- don't think pkgdesc should ever end with a dot
creeper-world2
- upstream source/url provides a https endpoint
- don't think pkgdesc should ever end with a dot
- unzip to prepare the env is more of a prepare() candidate
creeper-world3
- upstream source/url provides a https endpoint
- you can't reference the PKGBUILD like in prepare(), try building in a
clean chroot via extra-x86_64-build
- not a big fan of fiddling with PKGEXT even if its "just the AUR" but
well
csound-blue
- please don't use the AUR to store a tar.gz as a source
- provides/conflicts on itself doesn't do anything useful
- is there a reason for not stripping?
- this looks like a -bin package as you are re-distributing pre-compiled
files, why not just build from source instead? :)
gam
- don't think pkgdesc should ever end with a dot
- there is some unused client_secrets.patch sitting around in the source
repo
- python2-oauth2client dependency is missing
- this package create cluttering files across the filesystem if you run
gam as root, it will have untracked pyc files in /usr/share/gam/
you need to compile them if no distutils is provided
gnome-xcf-thumbnailer
- prepare() shall never package into $pkgdir
gtk-theme-adwaita-tweaks
- don't think pkgdesc should ever end with a dot
gtk-theme-adwaita-tweaks-git
- lack of provides/conflicts
- should pull via git+https://
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- the dark variant isn't published as "Adwaita Tweaks Dark" i don't
think this works compared to the non git variant, it should honor
the assets-dark folders and mimic what the release tarballs provide
gtk-theme-minwaita
- don't think pkgdesc should ever end with a dot
hib-dlagent
- none-url.patch is not a very unique name for a remote soruce, it could
potentially clash, prepend with $pkgname can help
imv-git
- lack of provides imv
i3lock-media-keys
- don't think pkgdesc should ever end with a dot
interception-ctrl2esc-git
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- provides/conflicts not proper
- is there a reason to have interception- prefix? imo ctrl2esc-git would
be the better naming here plus provides/conflicts on ctrl2esc
- you should use CMAKE_INSTALL_PREFIX=/usr and DESTDIR for $pkgdir
invada-studio-plugins-lv2
- don't think pkgdesc should ever end with a dot
lazy-ips-git
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- you can't reference the PKGBUILD like in prepare(), try building in a
clean chroot via extra-x86_64-build
- lack of provides/conflicts
linkchecker
- don't think pkgdesc should ever end with a dot
minecraft-technic-launcher
- don't think pkgdesc should ever end with a dot
nexuiz
- don't think pkgdesc should ever end with a dot
- upstream source/url both provides a https endpoint
- not a big fan of fiddling with PKGEXT even if its "just the AUR" but
well
- extracting and patching should be done in prepare()
- please don't use the AUR to store a tar.gz as a source, there is also
an orphan bin-links.tar.gz file additionally to the used
nex-icons.tar.gz checked into the AUR
pam_encfs
- doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure
this is always applied for c/cpp
pd-extended
- non unique filename that only contains the $pkgname, must always be
unique including the pkgver so avoid clashes
- doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure
this is always applied for c/cpp
- orphan file makefile.am.patch in the tree
- upstream source/url both provides a https endpoint
plasma5-applets-plasma-pass-git
- don't think pkgdesc should ever end with a dot
- conflicts missing on plasma5-applets-plasma-pass
python-google-auth-httplib2-git
- this is a split package creating two artifacts, you should not have
provides/conflicts on a global level, you need to put them in the
separate variants package_*() function once for python- and once for
python2-
- git makedepends is missing
python-humblebundle
- is there any reason to not just pull from github which also includes
the LICENSE? currently the LICENSE is separately pulled from git
master and it doesn't even have any unique file identifiers
python-image
- don't think pkgdesc should ever end with a dot
- don't use the hash based pythonhosted.org endpoint, there is a non
changing variant that is more suitable for packaging as it doesn't
very other then the $pkgver
python-image-git
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
python-oath
- don't think pkgdesc should ever end with a dot
- each variant must at least depend in its package_* func
to at least python/python2
- there are neat tests in the sources, please try to run a
check() function
python-vipaccess
- don't think pkgdesc should ever end with a dot
- you should add all the depends from the package_* funcs
to the makedepends so the check functions don't start
to uselessly download packages via pip
- setuptools is a hard depends and must be added in package_*
as the entry_point feature is used in the setup.py for
/usr/bin/vipaccess
- /usr/bin/vipaccess is provided in both variants it should by
something like vipaccess-py2 but this looks like a pure CLI
tool that is not really usable as a library, is it? If so,
it would be appropriate to just purge the python2 variant.
python2-image-git
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- why not use a split package via python-image-git like you do
for python-image?
- conflicts missing on python2-image
- LICENSE and README should be distributed, like in python-image-git
residualvm
- don't think pkgdesc should ever end with a dot
scanbd
- please don't use a install file to reference to the wiki, its not
meant to be used for such general purpose documentation
- upstream source provides a https endpoint
ttf-material-wifi-icons-git
- should pull via git+https://
- lack of provides/conflicts
unruu
- should use unique filename prefix with $pkgname-$pkgver
- should just pass --prefix=/usr to ./configure and call
a proper make DESTDIR="${pkgdir}" install
unruu-git
- git makedepends is missing
- lack of provides/conflicts
- should just pass --prefix=/usr to ./configure and call
a proper make DESTDIR="${pkgdir}" install
cheers,
Levente