Re: [aur-general] New package: disklow
One of the opt-depend packages my disklow is using, "msmtp-mta", is
containing a single symlink (/usr/bin/sendmail => msmtp). Perhaps, I should
have a look at its PKGBUILD (it's most likely simply calling "ln -s" in its
install() section).
But what would the symbolic link be needed for?
/usr/{bin,sbin}/sendmail provides the mail transport binary for the
various "mail" implementations. Sendmail, Msmtp, Postfix, etc, being
MTAs provide the system with this very basic means to send email.
Re: [aur-general] New package: disklow
On Tue, Sep 03, 2019 at 10:52:36 +1200, Holger Jahn wrote:
> > The AUR does not provide source code hosting, on the grounds that other
> > places like Github, Gitlab, git.sr.ht, amd so on are doing it better.
> > Moreover, source code hosting is a resource burden on the provider,
> > which in our case we do not have either a business or community
> > rationale for accepting. (Again: we provide hosting for build recipes
> > because build recipes are something specific to Arch).
>
> Makes sense, and I would not have done it "my way" if it weren't for the
> fact that my source code is a single Perl file with a mere 1400+ lines of
> code.
>
> Speaking of "borderline cases", such as mine:
IMNSHO 1400+ lines of Perl (or any) code don't fall into the category of
"borderline cases" at all.
> One of the opt-depend packages my disklow is using, "msmtp-mta", is
> containing a single symlink (/usr/bin/sendmail => msmtp). Perhaps, I should
> have a look at its PKGBUILD (it's most likely simply calling "ln -s" in its
> install() section).
package(), but yes:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/msmtp#n51
But what would the symbolic link be needed for?
> > More generally, why would you upload your project in a way that is
> > targeted exclusively for Arch users? What if users of a different distro
> > wanted to use your software?
>
> Because I am going to provide the packages for them myself.
I don't think one can realistically package something for all the
different distributions out there; you will inevitably end up excluding
quite a number of platforms.
I think this should have already been obvious enough while writing that
sendmail-setup.txt, where it only explains the setup steps for Arch and
CentOS, and for the others there is just:
[/usr/share/doc/disklow/sendmail-setup.txt]
> Please understand that there are so many different mail system setups
> in existence today, that it is impossible to cater for more than a few
> basic mail system configurations here.
Ó_ô
And by not providing a distro-agnostic source for obtaining the code,
this also discourages other people from stepping up and packaging it
themselves; it's unnecessarily cumbersome and I kind of see it as a
middle finger towards distribution packagers.
And because https://{that_url_there}/repos is not browsable, people
can't even know for what distributions the software has already been
packaged; that's a middle finger also to the distribution *users*.
And even for Arch users, reviewing the code becomes difficult, because
(as already mentioned):
On Mon, Sep 02, 2019 at 10:46:48 -0400, Eli Schwartz via aur-general wrote:
> > […] regardless of where you host it, why would you upload it as a
> > tarball checked into git?
Essentially, we lose all the nice VCS features, most notably the ability
to conveniently track changes: we now have to obtain the tarballs for
the old and the new version, extract them, and diff them manually.
--Tinu
signature.asc
Description: PGP signature
Re: [aur-general] New package: disklow
The AUR does not provide source code hosting, on the grounds that other places like Github, Gitlab, git.sr.ht, amd so on are doing it better. Moreover, source code hosting is a resource burden on the provider, which in our case we do not have either a business or community rationale for accepting. (Again: we provide hosting for build recipes > because build recipes are something specific to Arch). Makes sense, and I would not have done it "my way" if it weren't for the fact that my source code is a single Perl file with a mere 1400+ lines of code. Speaking of "borderline cases", such as mine: One of the opt-depend packages my disklow is using, "msmtp-mta", is containing a single symlink (/usr/bin/sendmail => msmtp). Perhaps, I should have a look at its PKGBUILD (it's most likely simply calling "ln -s" in its install() section). More generally, why would you upload your project in a way that is targeted exclusively for Arch users? What if users of a different distro wanted to use your software? Because I am going to provide the packages for them myself.
Re: [aur-general] New package: disklow
On September 2, 2019 4:47:08 PM GMT+02:00, Eli Schwartz via aur-general wrote: >On 9/2/19 6:50 AM, Khorne via aur-general wrote: > >> More importantly it seems to me that you switched url and source >> around. The source array is used to define where to find (and >> potentially download) the sources. The url array is just a general >> hint, for example to an upstream project page. >> >> As it stands, the pkgbuild assumes the sources to be in cwd as a >> file. If that's intentional, carry on. > >The url points to a valid prebuilt *.pkg.tar.xz, so that's not really a >"source" either. Granted, it turns out that's the case here. I didn't check the contents of the tarball but suspected as much.
Re: [aur-general] New package: disklow
On 9/2/19 6:50 AM, Khorne via aur-general wrote: > Few style things: > - remove unused directives > - packages always provide themselves Or as I prefer to describe it: Packages cannot logically provide themselves, they already *are* themselves. > More importantly it seems to me that you switched url and source > around. The source array is used to define where to find (and > potentially download) the sources. The url array is just a general > hint, for example to an upstream project page. > > As it stands, the pkgbuild assumes the sources to be in cwd as a > file. If that's intentional, carry on. The url points to a valid prebuilt *.pkg.tar.xz, so that's not really a "source" either. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] New package: disklow
On 9/2/19 7:31 AM, Holger Jahn wrote: > Hi Daniel, > > Thanks for your review. > >> You'll need to install the PerlArtistic license. > > What exactly do you mean by "install the license"? Put a copy of it into > the package? core/licenses provides /usr/share/licenses/common/PerlArtistic/license.txt If you were actually in need of installing the license, then you would do so in accordance with https://wiki.archlinux.org/index.php/PKGBUILD#license >> This may be a small tool, but you're not really supposed to host the >> source code in the AUR. It should be hosted elsewhere and downloaded. > > The payload code is one Perl script with 1400+ lines. > > For brevity's sake I am trying to keep it in one package, but if the > community rules dictate to split it into PKGBUILD & source, then so be it. The AUR graciously provides hosting for build recipes (PKGBUILD) and additional files needed for packaging (desktop files, those tiny shellscript wrappers which the java ecosystem is accursed with, kernel .config files, systemd units if upstream doesn't provide them, etc). The AUR does not provide source code hosting, on the grounds that other places like Github, Gitlab, git.sr.ht, amd so on are doing it better. Moreover, source code hosting is a resource burden on the provider, which in our case we do not have either a business or community rationale for accepting. (Again: we provide hosting for build recipes, because build recipes are something specific to Arch). We actually have a rudimentary enforcement method in the form of an upload validation script that will reject packages containing files which are "too big" and therefore seem like they cross the line from packaging files to source code. ... More generally, why would you upload your project in a way that is targeted exclusively for Arch users? What if users of a different distro wanted to use your software? And, regardless of where you host it, why would you upload it as a tarball checked into git? git already has excellent deduplication algorithms and the ability to diff versions of a file, but it is geared to text and is kind of terrible at handling often-changing binary files like a gzipped tarball. Over time, a repo containing tarballs will balloon in size. >> MD5 is old (and, some would argue, busted). Prefer SHA1, or better, >> SHA256. > > I wrote a little build script in order to wrap everything into the > package itself. The script uses > > makepkg -g >> PKGBUILD > > which produces the md5sums array. How do I get it to use something else > than md5sum? Simply roll my own by using sha256sum? makepkg -g will generate new checksums for a PKGBUILD, using all the current checksum algorithms listed in the PKGBUILD, or, if there are none, using the INTEGRITY_CHECK setting in makepkg.conf The INTEGRITY_CHECK defaults to md5. ... Aside: using makepkg -g >> PKGBUILD will lead to repeatedly appending checksum lines, which you will need to edit in order to remove old versions. The updpkgsums script from pacman-contrib will use makepkg -g in order to update checksums in-place. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] New package: disklow
Holger,
On Mon, Sep 02, 2019 at 11:31:27PM +1200, Holger Jahn wrote:
> What exactly do you mean by "install the license"? Put a copy of it into the
> package?
I spoke too hastily here. Per the packaging guidelines [1] unusual
licenses should be installed in /usr/share/licenses/${pkgname}. However,
PerlArtistic actually appears to be included in the licenses package
already, so this isn't necessary in your case.
[1] - https://wiki.archlinux.org/index.php/PKGBUILD#license
> For brevity's sake I am trying to keep it in one package, but if the
> community rules dictate to split it into PKGBUILD & source, then so be it.
I think the aurweb maintainers will have the most to say about whether
this is an absolute requirement. I think the chief concern has been disk
space requirements on the server, so you could probably make the case
here that the script can just be included in the repo.
I personally still wouldn't do this just because I think it's a good
idea to keep source materials (which could theoretically be packaged by
other distros) separate from the packaging scripts themselves.
> How do I get it to use something else than md5sum? Simply roll my own
> by using sha256sum?
makepkg -g will generate whatever type of integrity check is already in
the PKGBUILD. So just make the last line of your PKGBUILD sha256sums=()
and then replace it with the output of makepkg -g.
--
Daniel Moch
dan...@danielmoch.com
http://djmoch.org
signature.asc
Description: PGP signature
Re: [aur-general] New package: disklow
Hi Daniel, Thanks for your review. You'll need to install the PerlArtistic license. What exactly do you mean by "install the license"? Put a copy of it into the package? This may be a small tool, but you're not really supposed to host the source code in the AUR. It should be hosted elsewhere and downloaded. The payload code is one Perl script with 1400+ lines. For brevity's sake I am trying to keep it in one package, but if the community rules dictate to split it into PKGBUILD & source, then so be it. MD5 is old (and, some would argue, busted). Prefer SHA1, or better, SHA256. I wrote a little build script in order to wrap everything into the package itself. The script uses makepkg -g >> PKGBUILD which produces the md5sums array. How do I get it to use something else than md5sum? Simply roll my own by using sha256sum? Regards, Holger
Re: [aur-general] New package: disklow
Hi Khorne, Thanks for your review. More importantly it seems to me that you switched url and source around. The source array is used to define where to find (and potentially download) the sources. The url array is just a general hint, for example to an upstream project page. I understand. The point here is that there are no source files to download and configure/make/makeinstall. Hence, I pointed the URL straight to the package file itself: https://www.loomsday.co.nz/repos/arch/disklow-1.2-2-any.pkg.tar.xz Is there an "official" place where I can upload the package itself? Or will I have to split it into PKGBUILD and source in order to play by the Arch rules? Happy to set up a local repository on my own rack server in a few weeks, though. Regards, Holger
Re: [aur-general] New package: disklow
On 02/09/2019 12:31, Holger Jahn wrote: Good evening, If someone would be interested in reviewing my first contribution to Arch, disklow, then that would be much appreciated. Many thanks, Holger In addition to what have already been said; should always quote variables containing paths (and most variables in general)
Re: [aur-general] New package: disklow
See my comments inline.
On Mon, Sep 02, 2019 at 10:31:54PM +1200, Holger Jahn wrote:
> Good evening,
>
> If someone would be interested in reviewing my first contribution to Arch,
> disklow, then that would be much appreciated.
>
> Many thanks,
>
> Holger
>
>
> ###
> ### maintainer: holger jahn
> ###
>
> pkgname=disklow
> pkgver=1.2
> pkgrel=2
> epoch=
I don't think it hurts anything to keep empty elements like epoch,
groups, etc. in here, but as a matter of taste I prefer to remove them
as I personally find things a bit more readable.
> pkgdesc='Disk space evaluation and notification for servers (think of "disk
> free" on steroids). Examines mounted file systems and reports the number of
> used/free/total blocks on screen. Sends email alert if file systems are
> running low on free disk space. Multiple integrated mail transport options.
> Quite useful when run via cron.'
> arch=('any')
> url="https://www.loomsday.co.nz/repos/arch/disklow-$pkgver-$pkgrel-any.pkg.tar.xz;
> license=(
> 'GPL'
> 'PerlArtistic'
You'll need to install the PerlArtistic license.
> )
> groups=()
> depends=(
> 'perl'
> 'perl-filesys-df'
> 'perl-config-general'
> 'perl-mail-sendmail'
> 'perl-net-smtp-ssl'
> 'perl-authen-sasl'
> )
> makedepends=()
> checkdepends=()
> optdepends=(
> 'msmtp-mta: minimalistic system sendmail command'
> 's-nail: minimalistic system mail command'
> 'cronie: for periodic disk space monitoring'
> )
> provides=(
> 'disklow'
> )
Not necessary to specify the package itself in the provides field.
> conflicts=()
> replaces=()
> backup=(
> 'etc/disklow.conf'
> )
> options=()
> install=
> changelog=
> source=(
> "$pkgname-$pkgver.tar.gz"
This may be a small tool, but you're not really supposed to host the
source code in the AUR. It should be hosted elsewhere and downloaded.
> )
> noextract=()
> validpgpkeys=()
>
> package() {
> cd "$pkgname-$pkgver"
> install -m0644 -Dt $pkgdir/etc disklow.conf
> install -m0755 -Dt $pkgdir/usr/bin/ disklow
> install -m0644 -Dt $pkgdir/usr/share/doc/disklowsendmail-setup.txt
> install -m0644 -Dt $pkgdir/usr/share/man/man1/ disklow.1
> gzip-f $pkgdir/usr/share/man/man1/disklow.1
> }
Mixing tabs and spaces in formatting is a pet peeve for me. Choose one
and be consistent. Another nit-pick: The closing brace should be
directly underneath the p in package.
>
> md5sums=('5c2cf37c25f75b680edf1c04122c2fbf')
MD5 is old (and, some would argue, busted). Prefer SHA1, or better,
SHA256.
--
Daniel Moch
dan...@danielmoch.com
http://djmoch.org
signature.asc
Description: PGP signature
Re: [aur-general] New package: disklow
On September 2, 2019 12:31:54 PM GMT+02:00, Holger Jahn wrote: >Good evening, > >If someone would be interested in reviewing my first contribution to >Arch, disklow, then that would be much appreciated. > >Many thanks, > >Holger Hi Holger, Few style things: - remove unused directives - packages always provide themselves More importantly it seems to me that you switched url and source around. The source array is used to define where to find (and potentially download) the sources. The url array is just a general hint, for example to an upstream project page. As it stands, the pkgbuild assumes the sources to be in cwd as a file. If that's intentional, carry on. Regards, Khorne
