Arch Linux

skoal

Member

From: Frequent Flyer Underworld

Registered: 2004-03-23

Posts: 612

Website

Newer 4.2.x package conflicts with older 4.0.x package

(The following question relates to this thread):

Orelien, thanks for the PKGBUILD's. It worked great.

PROBLEM:

In the midst of my own set of PKGBUILD's for the xfce4 set, I ran across a problem which is related to one of those packages, but relates more in part to the various ways Arch users can update and how a package maintainer should handle these types of exceptions.

* For the package "xfdesktop", the 4.1.90 (or soon to be 4.2) version installs a program called "xfce4-menueditor". Unfortunately, the 4.0.x series had a separate package called "xfce4-menueditor". Here's the problem I ran into:

I was upgrading each package from the "xfce4" group individually, versus the entire "group" package "xfce4". I assume most Arch'ers would do something like "pacman -Syu xfce4". If they do, they will not encounter a package conflict since in effect this will remove the entire "xfce4" packages associated with the old group. However, for those who are a little more "customizable" in upgrading (or just not familiar with upgrading an entire group at once), they will get a package conflict with the old "xfce4-menueditor" while trying to install "xfdesktop" from the new 4.1.90 release, since the program "xfce4-menueditor" already exists and that old package "xfce4-menueditor-1.05-1" was the owner, not "xfdesktop-4.0.6-1".

QUESTION(s):

1. How should a package maintainer properly handle this situation?

2. In addition, what if that old package contained other programs which a user might still want to keep, but would have to be removed because of just one file. I don't think that's the case with respect to the "xfce4" set, but on more general terms, have you seen such a case and what have you done to handle that situation?

3. My understanding of the "conflicts" section in a PKGBUILD doesn't seem to apply in this case, or am I mistaken?  Is there a "pre_install()" function to handle something like this, or just ignore the conflict all together, and leave it to the user?

I know I have ran across that same problem before in another competely unrelated package. I just removed the offending file manually and continued the upgrade/install.

thx.

neri

Forum Fellow

From: Victoria, Canada

Registered: 2003-05-04

Posts: 553

Re: Newer 4.2.x package conflicts with older 4.0.x package

QUESTION(s):

1. How should a package maintainer properly handle this situation?

conflicts=('xfce4-menumaker') is the way to go

2. In addition, what if that old package contained other programs which a user might still want to keep, but would have to be removed because of just one file. I don't think that's the case with respect to the "xfce4" set, but on more general terms, have you seen such a case and what have you done to handle that situation?

[root@sojus tobias]# pacman -Ql xfce4-menueditor
xfce4-menueditor /opt/
xfce4-menueditor /opt/xfce4/
xfce4-menueditor /opt/xfce4/bin/
xfce4-menueditor /opt/xfce4/bin/xfce4-menueditor
xfce4-menueditor /opt/xfce4/share/
xfce4-menueditor /opt/xfce4/share/locale/
xfce4-menueditor /opt/xfce4/share/locale/fr/
xfce4-menueditor /opt/xfce4/share/locale/fr/LC_MESSAGES/
xfce4-menueditor /opt/xfce4/share/locale/fr/LC_MESSAGES/xfce4-menueditor.mo

there is nothing else, just the editor (the binary and a french localization file, that's it)

3. My understanding of the "conflicts" section in a PKGBUILD doesn't seem to apply in this case, or am I mistaken?  Is there a "pre_install()" function to handle something like this, or just ignore the conflict all together, and leave it to the user?

conflicts=() should handle this absolutely apropriately, this what this tag is made for.

-neri