lz4 upgrade file conflict (minor)

DaveCode · 2014-03-25 02:44:10

Recent lz4 upgrade (113-1 to 116-1) gave a pacman error failure,

lz4: /usr/lib/liblz4.so.1 exists in filesystem

on two different boxes and architectures. Strangely, pacman -Qo reported no owner on that file. WTF?

Deleting it by hand solved the problem but I'm curious why this incident happened and if it did to anyone else out there. I'm not sure it qualifies as an official bug so I didn't report it as such but posted here; someone tell me if that was wrong.

karol · 2014-03-25 02:57:10

Got the same error.

$ ls -l /usr/lib/liblz4.so.1
lrwxrwxrwx 1 root root 9 Mar 25 03:50 /usr/lib/liblz4.so.1 -> liblz4.so
$ pacman -Qo /usr/lib/liblz4.so
/usr/lib/liblz4.so is owned by lz4 113-1

I reported it https://bugs.archlinux.org/task/39618

Scimmia · 2014-03-25 04:37:34

Don't care where the symlink points to, where did it come from?

karol · 2014-03-25 04:45:42

It came from lz4 113:

$ ls -l /usr/lib/liblz4.so.1
ls: cannot access /usr/lib/liblz4.so.1: No such file or directory
[test]$ sp -U lz4-113-1-i686.pkg.tar.xz
loading packages...
resolving dependencies...
looking for inter-conflicts...

Packages (1):

Name  New Version  Net Change

lz4   113-1          0.16 MiB 

Total Installed Size:   0.16 MiB 

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                               [###########################################] 100%(1/1) checking package integrity                                             [###########################################] 100%
(1/1) loading package files                                                  [###########################################] 100%(1/1) checking for file conflicts                                            [###########################################] 100%
(1/1) checking available disk space                                          [###########################################] 100%(1/1) installing lz4                                                         [###########################################] 100%
$ ls -l /usr/lib/liblz4.so.1
lrwxrwxrwx 1 root root 9 Mar 25 03:58 /usr/lib/liblz4.so.1 -> liblz4.so

Allan · 2014-03-25 04:56:39

Well... not quite....

The previous package has liblz.4.so but not liblz.4.so.1. That file had "Library soname: [liblz4.so.1]", and as the symlink was not provided, ldconfig created it. So it is an untracked file.

Nothing that can be done from a packaging point of view here. Users will just have to delete the untracked file.

karol · 2014-03-25 05:27:14

I don't know what that means ... Can I apply for a refund anyway? ;P

Do you think it warrants a news item on the front page? lz4 is not an incredibly popular package, and the installed package base according to https://www.archlinux.de/?page=PackageStatistics is relatively small.

Allan · 2014-03-25 05:52:12

Front page news is not warranted. As you said, there is a small user base and the error is simple to deal with.

gilmoreja · 2014-03-25 14:12:30

karol wrote:

I don't know what that means ...

It means this:

# rm /usr/lib/liblz4.so.1

karol · 2014-03-25 14:13:07

There may be more to it: https://bbs.archlinux.org/viewtopic.php?id=179048

WonderWoofy · 2014-03-25 15:00:12

karol wrote:

There may be more to it: https://bbs.archlinux.org/viewtopic.php?id=179048

I am able to boot find with the new lz4 package and the kernel's EFISTUB...

Edit: I even just rebuilt the initramfs just in case the ordering of the update had some influence and still no issues.

Last edited by WonderWoofy (2014-03-25 15:03:41)

karol · 2014-03-25 15:04:58

False alarm then.
https://bbs.archlinux.org/viewtopic.php … 4#p1396724

DaveCode · 2014-03-26 02:58:08

Ah yes, explained.

Now, post upgrade, pacman gives ownership on the file.

$ pacman -Qo  /usr/lib/liblz4.so.1
/usr/lib/liblz4.so.1 is owned by lz4 116-1

So the package files changed between versions? Then omission was a packaging error, now fixed, I presume?

And: does anyone know a simple script to deal with these strays in advance of upgrades? I'd be happy to let a script scan for them first.

Last edited by DaveCode (2014-03-26 02:58:58)

karol · 2014-03-26 03:01:04

You can script it if you want: https://bbs.archlinux.org/viewtopic.php?id=130138

Scimmia · 2014-03-26 03:22:28

DaveCode wrote:

So the package files changed between versions? Then omission was a packaging error, now fixed, I presume?

Not a packaging error, but an upstream bug. These symlinks are expected to be made by the Makefile, but it wasn't set up correctly.

hoschi · 2014-03-26 12:56:45

Allan wrote:

Front page news is not warranted. As you said, there is a small user base and the error is simple to deal with.

Pacman is doing the job here just fine. From a technical point of view everything is alright!
And a printing a help message seems to be difficult, because their is already the right one printed from pacman also.

Couldn't a package-maintainer use the changelog-feature for publishing warnings about such issues? Maybe we could also make this changelog viewable via the only package database.
At least, a note within the svn commit could help much (may avoid unnecessary bugs in flyspray?) as offical guidance? The svn-log is first source for me, beside the forum and flyspray.

I've installed lz4 from the habit to be apple to open all (sane) archive files which are possible in the wild. So I'm afraid you're right about the front page.

DaveCode · 2014-03-27 02:08:54

So here's the upstream makefile fix.

How is Arch's package file list made for the web: by file listing diff pre/post install? by hand? install script parsing? maintainer's discretion? Thanks. I often use those file listings so it may help to know where they are made.

A very few pkgs always cause file conflict error. Was it apache-ant or nodejs some other Java-ish thing? Can't recall. Could use a new /etc/pacman.conf flag like

ForcePkg  =  nodejs  apache-ant

to apply --force to single packages individually during general upgrades. Or being more fine-tuned, a ForceUpgrade converse of NoUpgrade to name files within a package.

Allan · 2014-03-27 02:25:55

We are not adding options to pacman to deal with upstream software failures. Especially given I have not seen something like this before...

The file lists are generated by looking at the package archive.

Arch Linux

#1 2014-03-25 02:44:10

lz4 upgrade file conflict (minor)

#2 2014-03-25 02:57:10

Re: lz4 upgrade file conflict (minor)

#3 2014-03-25 04:37:34

Re: lz4 upgrade file conflict (minor)

#4 2014-03-25 04:45:42

Re: lz4 upgrade file conflict (minor)

#5 2014-03-25 04:56:39

Re: lz4 upgrade file conflict (minor)

#6 2014-03-25 05:27:14

Re: lz4 upgrade file conflict (minor)

#7 2014-03-25 05:52:12

Re: lz4 upgrade file conflict (minor)

#8 2014-03-25 14:12:30

Re: lz4 upgrade file conflict (minor)

#9 2014-03-25 14:13:07

Re: lz4 upgrade file conflict (minor)

#10 2014-03-25 15:00:12

Re: lz4 upgrade file conflict (minor)

#11 2014-03-25 15:04:58

Re: lz4 upgrade file conflict (minor)

#12 2014-03-26 02:58:08

Re: lz4 upgrade file conflict (minor)

#13 2014-03-26 03:01:04

Re: lz4 upgrade file conflict (minor)

#14 2014-03-26 03:22:28

Re: lz4 upgrade file conflict (minor)

#15 2014-03-26 12:56:45

Re: lz4 upgrade file conflict (minor)

#16 2014-03-27 02:08:54

Re: lz4 upgrade file conflict (minor)

#17 2014-03-27 02:25:55

Re: lz4 upgrade file conflict (minor)

Board footer