[aur-requests] [PRQ#18054] Deletion Request for usb-notify-git

[Eli Schwartz]

On 2/23/20 10:29 PM, Wayne Campbell wrote:
> On Sun, Feb 23, 2020 at 7:35 PM <notify at aur.archlinux.org> wrote:
>>
>> eschwartz [1] filed a deletion request for usb-notify-git [2]:
>>
>> self-published program with no votes, doesn't seem to be generally
>> useful.
> I would politely disagree, As I feel that if you are running a minimal
> install and want information about usbs using libnotify it's useful. I
> do however admit that the package doesn't have any votes.

I'll admit that is a bit of an iffy complaint. Fair enough.

>> This runs sudo make install in package() to install directly to
>> /usr/local
> After seeing this comment, I have learned about the .install scripts.
> Is this comment insinuating that I use that method instead of the make
> file? I'm quite interested in doing this the _right_ way.

Your PKGBUILD contain this:

package() {
    cd "$srcdir/${_pkgname}"
    make && sudo make install
}

This builds the package in the package() function instead of the build()
function, then elevates to root, assuming the user actually has sudo
permissions, and installs untracked files to /usr/local.

The purpose of a PKGBUILD and the package() function is generally
described here:
https://wiki.archlinux.org/index.php/Creating_packages#package()

The idea is that you want to install the files to the package not to
/usr, and that means installing the files to "${pkgdir}/usr/bin".

Until the files are installed to "${pkgdir}" rather than /usr, this
*isn't even a package*.

Side note: since you mention being interested in doing things the right
way, allow me to pontificate on some nifty Makefile tricks.

https://github.com/wcampbell0x2a/usb-notify/blob/master/Makefile#L28

Conventionally, Makefiles have an install target that:

a) uses PREFIX ?= /usr/local, which allows people to make install
   PREFIX=/usr if they don't want to use the /usr/local hierarchy,

b) install to $(DESTDIR)$(PREFIX)/bin/ so that linux distributions can
   do make install DESTDIR=${some_package_manager_staging_directory}

These methods can be combined, or used in autotools-based build systems
as ./configure --prefix=/usr to define the PREFIX, etc. But for simple
Makefiles, you'd generally want to change:

install:
    install -m 755 ./bin/usb-notify /usr/local/bin/usb-notify

to

PREFIX ?= /usr/local

install:
    install -m 755 ./bin/usb-notify '$(DESTDIR)$(PREFIX)/bin/usb-notify'

In the PKGBUILD, you'd then execute:

build() {
    cd "$srcdir/${_pkgname}"
    make
}

package() {
    cd "$srcdir/${_pkgname}"
    make install DESTDIR="${pkgdir}" PREFIX=/usr
}


Also, CFLAGS is being misused, as `pkg-config --cflags --libs libnotify`
belongs in LIBS (and should be defined as $(shell pkg-config ....) to do
assignment right there, rather than injecting it into the gcc command line).

And per
https://www.gnu.org/software/make/manual/make.html#Implicit-Variables
the convention is to rename LIBS to LDLIBS.

If you do that you can even use the built-in rules for %.o: %.c and %:
%.o as documented by
https://www.gnu.org/software/make/manual/make.html#Catalogue-of-Rules

Once CFLAGS is no longer being used to define the libnotify LIBS (or
LDLIBS), I would advise using the assignment form "CFLAGS ?=" because
makepkg can set a bunch of its own CFLAGS which it is generally
preferred to use, and can for example define -g depending on whether the
makepkg.conf profile has enabled debug builds.

e.g.

CFLAGS ?= -g
CFLAGS += -ansi -pedantic -std=c99  -W -Wextra -Wall

Using this pattern you could have flags which are imported from the
environment, if set, but otherwise default to some that you have set.
And you can also have some which you have set and consider crucially
important which should additionally be used.

-- 
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/adb3a2e2/attachment.sig>