Arch Linux

G_Syme

Member

Registered: 2007-01-04

Posts: 83

"conflicts/provides" problem with splitted package

I'm currently working on some brother printer packages and have the following situation:

I want to replace the not-working package brother-mfc260c in AUR, and have made two packages, brother-mfc260c-lpr (the LPR driver) and brother-mfc260c-cupswrapper (the LPR-to-CUPS wrapper), which together provide what the old package should do (or have done).

Here are the dependency specs from the new PKGBUILDs:

brother-mfc260c-lpr:

conflicts=('brother-mfc260c')

brother-mfc260c-cupswrapper:

depends=('brother-mfc260c-lpr')
conflicts=('brother-mfc260c')           # This could also be omitted because its dependency already conflicts with brother-mfc260c
provides=('brother-mfc260c=1.0.1')

But pacman doesn't like it. Whether I try to install both packages at the same time, or install brother-mfc260c-lpr first, and then brother-mfc260c-cupswrapper (like below), I get the same error:

# pacman -U brother-mfc260c-cupswrapper-1.0.1_1-1-i686.pkg.tar.gz
loading package data...
checking dependencies...
error: replacing packages with -U is not supported yet
error: you can replace packages manually using -Rd and -U
error: failed to prepare transaction (conflicting dependencies)
:: brother-mfc260c-cupswrapper: conflicts with brother-mfc260c-lpr

Should I file a bug report, or is this behavior intended? If the latter case applies, how can I solve such a conflict without loss of generality?

Thanks in advance!

---

The courageous enter dark caves alone.
The clever send in the courageous first.
The cleverest wait behind the clever.

Ramses de Norre

Member

From: Leuven - Belgium

Registered: 2007-03-27

Posts: 1,289

Re: "conflicts/provides" problem with splitted package

Did you thoroughly read the error message?

error: replacing packages with -U is not supported yet
error: you can replace packages manually using -Rd and -U

Use -Rd or set up a repo to correctly test the pacman behaviour.

G_Syme

Member

Registered: 2007-01-04

Posts: 83

Re: "conflicts/provides" problem with splitted package

Maybe I should have been more verbose. Yes, I have read the error message.
As stated before I've also tested to install both packages at the same time:

pacman -U brother-mfc260c-lpr-1.0.1_1-1-i686.pkg.tar.gz brother-mfc260c-cupswrapper-1.0.1_1-1-i686.pkg.tar.gz
loading package data...
checking dependencies...
error: conflicting packages were found in the target list
error: you cannot install two conflicting packages at the same time
error: failed to prepare transaction (conflicting dependencies)
:: brother-mfc260c-lpr: conflicts with brother-mfc260c-cupswrapper

The general problem seems to be that it is difficult to tell for a package manager whether these packages really conflict with one another or whether they form an entity which then conflicts against a common package. E.g. for an svn version of a package like:

conflicts=("${pkgname%-svn}")
provides=("${pkgname%-svn}")

the probability that the package conflicts with itself can be considered zero, but if the provides and conflicts statements are "distributed" over more than one package (like in my case), this decision isn't so trivial any more. Because of that I suspect that pacman cannot handle this kind of problems. And that is why I ask the community whether I have missed something here or whether I should file a bug report.

---

The courageous enter dark caves alone.
The clever send in the courageous first.
The cleverest wait behind the clever.

Profjim

Member

From: NYC

Registered: 2008-03-24

Posts: 658

Re: "conflicts/provides" problem with splitted package

Can you confirm that you've already manually removed brother-mfc260c? Because as some of your error messages seem to state, you're trying to install with -U a package that may be conflicting with the already-installed brother-mfc260c. I think pacman knows to remove the existing package and install the new conflicting package, but only when the install is from a repo, not when one is using -U blahblah.pkg,tar.gz.

If we know for sure that this isn't an issue here, then we can focus on what you think is the problem, namely that pacman is applying the "conflicts" statement against the "provides" statement.

If your diagnosis is right, then I think this is probably a feature request, not a bug. You should feel free to let the dev team know about the kind of use case (yours) for which the extra functionality you're requesting would be useful. Myself I'm not clear about how the dependency/provides mechanism should be redesigned to accommodate what you want to do.

I can imagine a workaround within the existing system. It does however require one more entry in the package database:

* brother-mfc260c-lpr-shared  doesn't conflict with or provide anything
* brother-mfc260c-lpr  is an empty package that depends on brother-mfc260c-lpr-shared and conflicts with brother-mfc260c
* brother-mfc260c-cups  also depends on brother-mfc260c-lpr-shared and conflicts with brother-mfc260c, and additionally provides brother-mfc260c.

Won't that work?

G_Syme

Member

Registered: 2007-01-04

Posts: 83

Re: "conflicts/provides" problem with splitted package

Can you confirm that you've already manually removed brother-mfc260c?

Sorry for not mentioning this earlier. I've never installed brother-mfc260c on my machine to begin with, because I don't even have such a printer. But I've successfully created such a package pair for the brother-mfc210c, and have read on the AUR page of the orphaned brother-mfc260c package the comment "The driver is not working... DELETE!!!", so I've made a package pair for this model in a similar style. And the brother-mfc210c package pair only works with the above mentioned provides/conflicts statements because its provides-statement has a typo which I've found after uploading it to AUR.

To make a long story short, because of these two facts (never installed the real brother-mfc260c, and the typo in the brother-mfc210c-* packages), I'm quite positive about understanding how the provides/conflicts mechanism works.

I think pacman knows to remove the existing package and install the new conflicting package, but only when the install is from a repo, not when one is using -U blahblah.pkg,tar.gz.

I couldn't understand why this should matter from where a package is installed. IMHO this is a totally different layer of abstraction. But I'll make a test repo tomorrow to clear this question.

Concerning your 3-package-suggestion, this wouldn't fit right away because both real packages have to conflict with the original one, because it is ~just~ a split of that package. And maybe there are still some people around using only the LPR driver and not the CUPS wrapper on top of it.

After testing your suggestion, I'll post a feature request and will link it to this thread. AFAICT interpreting a conflicts statement not only against a package with the exact name but also against packages which provide that one is simply a design decision, and not clearly right or wrong. Would it only conflict against a given package, all other packages which provide that one and have files in common would have to be listed in the conflicts array, too.

For the moment I've solved the problem by simply removing the provides-statement, because there is no package explicitly depending on brother-mfc260c, and the probability of it happening will be quite next to zero, but the basic problem still remains, and that's why I wanted to consult the community first before giving the devs extra work.

---

The courageous enter dark caves alone.
The clever send in the courageous first.
The cleverest wait behind the clever.

G_Syme

Member

Registered: 2007-01-04

Posts: 83

Re: "conflicts/provides" problem with splitted package

I've tested it today with a local repo instead of using pacman -U, and as I've expected, it makes no difference.
I've now opened a feature request.

---

The courageous enter dark caves alone.
The clever send in the courageous first.
The cleverest wait behind the clever.