Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#17801 - [makepkg] contents of .install files should go in PKGBUILD

Attached to Project: Pacman
Opened by Joseph Thursby (quitr) - Tuesday, 12 January 2010, 14:44 GMT
Last edited by Allan McRae (Allan) - Saturday, 06 March 2010, 11:15 GMT
Task Type Feature Request
Category makepkg
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:

The contents of .install files such as post_install() and post_upgrade() should go in the PKGBUILD file so variables such as ${pkgname} can be used on them.

Steps to Reproduce:

Suppose a PKGBUILD installs documentation at /usr/share/doc/${pkgname} and the user needs to view important information/config files before using the package.

If you want to tell the user to view /usr/share/doc/${pkgname} post-installation, you can't use the variable ${pkgname}. The designer of the PKGBUILD is forced to hard code the package's name into the .install file (or create a new variable in the install file).

In my opinion this creates bad programming habits in regard to .install files. makepkg should be capable of extracting the necessary functions from the PKGBUILD file and inserting them into the final pkg file.

Even if we keep the .install files, the variables should somehow be carried over to them so good programming practices can take place.
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 06 March 2010, 11:15 GMT
Reason for closing:  Won't implement
Comment by Dan McGee (toofishes) - Tuesday, 12 January 2010, 14:51 GMT
OMG I used the hardcoded pkgname in the install file! The humanity! :)

I'm trying to figure out when this would be useful. At least for Arch, we try to never have install messages like the one you mentioned because it just adds noise. And bad programming habits? Even that seems like a stretch to me...

Allan, thoughts? I know we had the topic come up in the past where simple install files could be inlined in the PKGBUILD, but even that ran up against the roadblock of variables (as we decided it would be too hard to figure out what to keep and what can go). In addition, split packages would present a whole new hurdle that we didn't have the previous go-around of ideas like this.
Comment by Allan McRae (Allan) - Tuesday, 12 January 2010, 14:55 GMT
The issue is how to extract the function from the PKGBUILD so it can be sourced (as root...) and nothing else in the PKGBUILD be run.

But I can solve this. The the top of your install file put:
pkgname=foobar
then use that variable to you hearts content.
Comment by Dan McGee (toofishes) - Tuesday, 12 January 2010, 15:00 GMT
Haha that was my thought too. It is KISS in all ways except one small line of extra information, and doesn't require us to add ~100 lines of code to makepkg to try and hack this in.

Loading...