You are not logged in.

#1 2015-06-30 11:22:27

Colin.Smith
Member
Registered: 2015-06-09
Posts: 3

Pacman doesn't record the root of packages that are installed

Hi,

I've found a couple of bugs in how Pacman (v4.2.1-160-g3d4529 - libalpm v9.0.1) handles/records root directory information. In this use case I'm using pacman simply to install some zip files, rather than for Arch Linux binary packages.

If I install a package to a non default root, but use the system cache and package database as follows:

pacman -Sy --root /tmp/datatest --cachedir /var/cache/pacman/pkg --dbpath /var/lib/pacman --noconfirm  variant-apollo

It downloads and installs the packages exactly as you would expect.

# pacman -Qi variant-apollo
Name           : variant-apollo
Version        : 08.030.0057.0115-1
Description    : Variant packages
Architecture   : any
URL            : None

But it doesn't seem to record the root directory of the package install.
e.g.

# pacman -Qlv variant-apollo
Root      : /
Conf File : //etc/pacman.conf
DB Path   : /var/lib/pacman/
Cache Dirs: //var/cache/pacman/pkg/ 
Lock File : /var/lib/pacman/db.lck
Log File  : //var/log/pacman.log
GPG Dir   : //etc/pacman.d/gnupg/
Targets   : variant-apollo
variant-apollo /File1.zip
variant-apollo /File2.zip
...


Looking in the local package database I don't see an obvious place where the information would be recorded, though perhaps desc might be the
appropriate place for the information. Or in the mtree file:
/ set type=file uid=0 gid=0 mode=644 ?

#mtree
/set type=file uid=0 gid=0 mode=644
./.PKGINFO time=1434624618.20589000 size=508 md5digest=c2737aa3751f590ba5521829875c1905 sha256digest=64617530135f541235f32daaf7b00ed510a8c8f1ab12847659a6bd218c3d26d4
./File1.zip time=1434544034.136922000 size=1006397321 md5digest=a39ffd96d80811ab2d751124b9fc6c27 sha256digest=81de253de7d716bf5c419f90444cb6252359dcfc279b57cd2a99ff571d3bc07c
./File2.zip time=1434544053.624031000 size=379516586 md5digest=3105df69f1f7a441feb5044a816da126 sha256digest=f5dae2145fc13419310c3c1e6c7b697f2f1c100ab8fda59214da5739fe216c10
...
# ls -l /tmp/datatest/
total 55214292
-rw-r--r-- 1 root root 1006397321 Jun 17 14:27 File1.zip
-rw-r--r-- 1 root root  379516586 Jun 17 14:27 File2.zip
...

When I come to remove the package:

# pacman -R variant-apollo
checking dependencies...

Packages (1) variant-apollo-08.030.0057.0115-1

Total Removed Size:  53919,99 MiB

:: Do you want to remove these packages? [Y/n] Y
(1/1) removing variant-apollo                      [#################] 100%
# echo $?
0

All seems well, exit status is 0 (successful) and in the log, all is recorded as well.

[2015-06-30 12:32] [PACMAN] Running 'pacman -R variant-apollo'
[2015-06-30 12:32] [ALPM] transaction started
[2015-06-30 12:32] [ALPM] removed variant-apollo (08.030.0057.0115-1)
[2015-06-30 12:32] [ALPM] transaction completed

Indeed the package record is removed from the local package database:

# ls -l /var/lib/pacman/local
total 4
-rw-r--r-- 1 root root 2 Jun 18 15:04 ALPM_DB_VERSION

But the installed files have not been removed:

# ls -l /tmp/datatest/
total 55214292
-rw-r--r-- 1 root root 1006397321 Jun 17 14:27 File1.zip
-rw-r--r-- 1 root root  379516586 Jun 17 14:27 File2.zip
...

The successful exit status and log entries while removing the package DB entry and leaving behind the contents of the package is definitely a bug.

The expected behavior would be to record the root information in the local package database with the package, then when queried it could display the correct paths to the data files and on removal, it could also remove the files from the correct paths.

If I always specify the --root option on the command line it does work as you would expect on removal, but this means the root information then has to be managed outwith the package system.

I'm going to have a look in the code of pacman and libalpm and see if I can work out what's happening.

Last edited by Colin.Smith (2015-06-30 11:24:28)

Offline

#2 2015-06-30 11:43:27

Raynman
Member
Registered: 2011-10-22
Posts: 1,539

Re: Pacman doesn't record the root of packages that are installed

man pacman wrote:

-r, --root <path>
Specify an alternative installation root (default is /). This should not be used as a way to install software into /usr/local instead of /usr. This option is used if you want to install a package on a temporarily mounted partition that is "owned" by another system.  NOTE: If database path or log file are not specified on either the command line or in pacman.conf(5), their default location will be inside this root path.

Offline

#3 2015-06-30 12:09:58

Spider.007
Member
Registered: 2004-06-20
Posts: 1,176

Re: Pacman doesn't record the root of packages that are installed

Like Raynman quotes, --root should be used for actual-root directories, not simply a 'random' path where you'd like your files to end up. Mixing --root with --dbpath seems like an accident waiting to happen and I'm pretty sure this sort of usage is not recommended nor supported.

Last edited by Spider.007 (2015-06-30 12:10:16)

Offline

#4 2015-06-30 14:39:26

Colin.Smith
Member
Registered: 2015-06-09
Posts: 3

Re: Pacman doesn't record the root of packages that are installed

I see. I'll take it as a known limitation of the current release of pacman/libalpm. The use case for the current --root argument is in this context is relatively limited, though in my case the use of --root and --dbpath wouldn't cause problem as long as it remains consistent in the short term.

So essentially, an additional "root", --instdir,  "install base" or --relocate like argument would be needed to allow proper support for relocatable packages. Along with internal pacman and package database support for the added functionality.

Offline

#5 2015-06-30 23:02:44

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,672
Website

Re: Pacman doesn't record the root of packages that are installed

It is not a missing feature - most packages will not work when the binaries are installed in a different root.  The root needs to be configured at compile time.

Offline

Board footer

Powered by FluxBB