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#13551 - [Feature Request] Check for backup files existence

Attached to Project: Pacman
Opened by Xavier (shining) - Thursday, 26 February 2009, 14:46 GMT
Last edited by Allan McRae (Allan) - Monday, 07 September 2009, 05:48 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Xavier (shining)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.2
Due in Version 3.4.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I just noticed that wrong backup files entries go totally unnoticed.
See for example  FS#13547   FS#13548  and  FS#13549 

These errors can not really be checked at the PKGBUILD level, but at the package level it should be easy enough. However, namcap does not display any warnings on these packages.

pacman does not display any warnings when installing them : the missing backup files are stored in the database without their corresponding md5sum
%BACKUP%
etc/ufw/before.rules e5f58e321f38dd7534380937b470c928
etc/ufw/user.rules
etc/ufw/after.rules 3a51c36bfd12a053c50860a6b332e2d2
sysctl.conf
etc/ufw/ufw.conf 477a9a8b7d2f6d89f74c5ee469a9c4d3

and pacman -Qii silently ignores the non existent entries :
Backup Files:
Not Modified /etc/ufw/before.rules
Not Modified /etc/ufw/after.rules
Not Modified /etc/ufw/ufw.conf

It is not a big deal, but I just thought I would report it somewhere in case anyone cares :)
This task depends upon

Closed by  Allan McRae (Allan)
Monday, 07 September 2009, 05:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  git commit b53aa87e
Comment by Xavier (shining) - Thursday, 26 February 2009, 15:05 GMT
Here is an ugly bash line to find the backup entries in the local db with no md5sum :

% grep -A20 -r BACKUP /var/lib/pacman/local | egrep -v "BACKUP|files\-$|^\-\-$" | egrep -v "[a-f0-9]{10}"

/var/lib/pacman/local/ntp-4.2.4p6-1.1/files-conf.d/ntp-client.conf
/var/lib/pacman/local/ufw-0.26-1/files-etc/ufw/user.rules
/var/lib/pacman/local/ufw-0.26-1/files-sysctl.conf
/var/lib/pacman/local/lirc-utils-0.8.3-1/files-etc/lircd.conf
/var/lib/pacman/local/lirc-utils-0.8.3-1/files-etc/lircmd.conf
/var/lib/pacman/local/udev-135-1/files-etc/udev/cdsymlinks.conf
/var/lib/pacman/local/pacman-3.2.2-1/files-etc/pacman.d/mirrorlist
/var/lib/pacman/local/foomatic-filters-4.0_20090211-1/files-/etc/foomatic/filter.conf

As I mentioned in the original report, I already reported a bug for ntp, ufw and foomatic-filters. But not for lirc-utils, udev and pacman.
Comment by Gavin Bisesi (Daenyth) - Saturday, 21 March 2009, 15:02 GMT
Status?
Comment by Roman Kyrylych (Romashka) - Sunday, 31 May 2009, 14:11 GMT
@ Xavier: do you think this can be solved in pacman?
Comment by Dan McGee (toofishes) - Tuesday, 02 June 2009, 01:34 GMT
What about solving this in makepkg? Right before (or after) we tar it up, we can check for the backup files existence, and also warn about leading '/' characters in the paths.
Comment by Allan McRae (Allan) - Tuesday, 02 June 2009, 01:52 GMT
Adding a check for invalid leading "/" in the backup entries is easy and fits in with the checks for invalid PKGBUILD entries we already do in makepkg.

Checking for missing backup files before taring up the package is also easy. I am wary about makepkg becoming too much of a package checking tool but it is becoming apparent at least some package checking needs done on this level (e.g  FS#14751 ).
Comment by Xavier (shining) - Tuesday, 18 August 2009, 18:30 GMT
a patch on my working branch
Comment by Allan McRae (Allan) - Tuesday, 18 August 2009, 19:46 GMT
The check for the leading "/" should be in the check_sanity() function, at which point erroring out would be fine.

The actual existence for of the files $pkgdir/${backup[@]} should be checked where your current check is. Name this function check_package() as other checks can go there (e.g. checking for $srcdir references).
Comment by Xavier (shining) - Tuesday, 18 August 2009, 19:55 GMT
does check_sanity handle split package, or is it called only for the top-level variables? or is this sufficient?
Comment by Allan McRae (Allan) - Tuesday, 18 August 2009, 20:16 GMT
Good point... check_sanity should actually be run during the package splitting (perhaps with errors reduced to warnings?). At the moment, I'd focus on getting the global case working.
Comment by Xavier (shining) - Wednesday, 19 August 2009, 06:36 GMT
new patch :)

Loading...