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#20314 - pacman incorrectly installs hard links over multiple partitions

Attached to Project: Pacman
Opened by Rémy Oudompheng (remyoudompheng) - Thursday, 29 July 2010, 12:07 GMT
Last edited by Dan McGee (toofishes) - Friday, 14 January 2011, 12:39 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 3.4.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
When pacman installs a package with hard linked files, we might except finding hard links in the system, or symlinks if this is not possible (for example, when hard links would span over multiple partitions). For most packages, this is a non-issue (for example, git is installed with a "no-cross-directory-hard-links" options).

Attached is an example PKGBUILD triggering the issue when / and /usr are separate partitions.

Steps to Reproduce:
* use the attached PKGBUILD or package

$ sudo pacman -U dummy-1-1-any.pkg.tar.gz
resolving dependencies...
looking for inter-conflicts...

Targets (1): dummy-1-1

Total Download Size: 0.00 MB
Total Installed Size: 0.03 MB

Proceed with installation? [Y/n]
checking package integrity...
(1/1) checking for file conflicts
(1/1) installing dummy
$ ls /etc/dummy/
alice
$ ls /usr/share/dummy/
   PKGBUILD (0.3 KiB)
(application/x-gzip)    dummy-1-1-any.pkg.tar.gz (0.5 KiB)
This task depends upon

Closed by  Dan McGee (toofishes)
Friday, 14 January 2011, 12:39 GMT
Reason for closing:  Implemented
Additional comments about closing:  Fixed in namcap, possibly pacman is more resilient as well.
Comment by Dan McGee (toofishes) - Thursday, 29 July 2010, 12:09 GMT
This would be the first time pacman has ever done on-the-fly manipulation of packages...I'm not really a huge fan of that.
Comment by Allan McRae (Allan) - Friday, 30 July 2010, 00:44 GMT
In the end, I think this would be considered a packaging issue. Should pacman just detect such occurrences and report an error so the packager can be informed about the issue rather than the current silent failure.

We should probably add a namcap check for cross-dir hard-links too.
Comment by Dan McGee (toofishes) - Friday, 30 July 2010, 00:57 GMT
I'd agree, although there probably are valid cases for cross-directory hard links. However, solving this in pacman is not the easiest:
* Where does the actual file go vs. some on the fly symlinks?
* Should we even be changing the package as hard links might be required?

We should probably be more explicit when an extraction like this fails, and yes a namcap check should definitely be added.
Comment by Pete (tam1138) - Thursday, 05 August 2010, 05:43 GMT
I agree that having pacman alter packages on the fly is suboptimal. Hardlinks are used quite seldom, and hardlinks across directories (let alone partitions) are even rarer, which is an argument to minimize distro-level engineering effort. In my mind, based on the guiding principles of KISS, minimal changes to upstream releases, and maximal user control, the only real option is to provide a warning upon installation. The user, being empowered, has chosen a particular partitioning scheme that just so happens to run afoul of some upstream author's preferred world vision. That's not our problem, we're just the middleman.
Comment by Dan McGee (toofishes) - Friday, 14 January 2011, 07:11 GMT
$ ./namcap-devel /tmp/dummy-1-1-any.pkg.tar.gz
dummy E: Cross-directory hardlink in package (usr/share/dummy/bob, etc/dummy/alice)
dummy E: Missing custom license directory (usr/share/licenses/dummy)

Namcap rule added: http://projects.archlinux.org/namcap.git/commit/?id=f6ed514afa8441c2dba6b2d2a3b6a78c27932bee

Should we close this?
Comment by Allan McRae (Allan) - Friday, 14 January 2011, 08:53 GMT
This might actually be one of the cases caught by the extra error checking we added to package extraction as part of the disk space checking.

So I think this can be closed.

Loading...