lcd font packages conflicting with original packages

blu3ness · 2008-01-13 07:21:49

Hello all, Today after upgrading pacman I tried to do pacman -Syu after changing all my config files to be using .pacnew versions.

And I was greeted with these messages

:: cairo conflicts with cairo-lcd. Remove cairo-lcd? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: cairo: conflicts with cairo-lcd

I love those lcd packages and they make the font look crispy clear, I'm wondering what are the workarounds for this problem? (yes I want to keep cairo-lcd and upgrade other stuff )

brebs · 2008-01-13 07:30:01

The PKGBUILD should contain:

provides=('cairo')

shining · 2008-01-13 09:12:54

It already contained that line. But with pacman 3.1, this isn't enough anymore.
The problem is that a few packages require a specific version of cairo, for example : depends=('cairo>=1.4.10')
For the providers of cairo (eg cairo-lcd) to satisfy this dependency, the provides line MUST specify a version. For example :

provides=('cairo 1.4.12')

See http://bugs.archlinux.org/task/9162

brebs · 2008-01-13 10:08:18

Hmm, that sucks. The version should be there as a *default*, with an override for the rare cases when the default causes a problem.

shining · 2008-01-13 10:56:14

brebs wrote:

Hmm, that sucks. The version should be there as a *default*, with an override for the rare cases when the default causes a problem.

Is it really that bad? How many packages really need to be fixed? Apparently not too much.
For now, only a few unofficial packages seem concerned : cairo-lcd , qtmod, and maybe a few others kdemod packages.
I don't think it's that hard to fix, you just need to notice the maintainers of these packages and be patient.
Since cairo-lcd is a community package, this can be reported on flyspray, and already is.
For kdemod, you must have a look at their project.

zenlord · 2008-01-14 10:06:57

shining wrote:

How many packages really need to be fixed? Apparently not too much.

Nope:
- cairo-lcd
- libxft-lcd
- freetype2-lcd

These I had to remove before I could upgrade my system yesterday. Glad I'm not the only one and even more glad that I, after having made these changes will not be doing this with every update (i.e. almost every night )

Zl.

brebs · 2008-01-14 17:02:44

This is much better:

provides=("cairo $pkgver")

Although I still think that $pkgver should be the default version to include, unless one is specified.

blu3ness · 2008-01-15 00:12:05

what about the other packages? namely libxft-lcd, freetype2-lcd, do they only need the version number in their PKGBUILD?

Update

The answer is yes Thanks all.

Last edited by blu3ness (2008-01-15 00:59:20)

shining · 2008-01-15 11:20:31

I have bad news, there are problems with this syntax.

For example if an user forgot to put quotes in the PKGBUILD :

provides=(cairo 1.4.12)

This would be seen as two different provisions by makepkg : cairo and 1.4.12.

For a similar reason, db scripts like repo-add are confused by this syntax and don't handle it properly.
repo-add could be fixed, but we would still have problems with the above case where quotes were forgotten.
The other scripts dealing with these provide arrays would also need to be checked.

That's why we are considering changing the syntax to the following :

provides=(cairo=1.4.12)

schivmeister · 2008-01-16 18:21:10

Well, it looks like my whole system is victim to this. Why? Because this is 60% AUR & kdeMOD! No big updates yet so it's not much of a PITA. For most that have no conflicts, just adding --nodeps does it. But for those that do have conflict, a rebuild is required.

But at the end of the day, what this means is, practically, every single Arch Linux package must be updated to reflect the new standard. Arghh..lately i've been failing too much. Encountering segfaults with 1 application and namcap is always complaining about an integer on every package built. Too used to a perfect system, life as a geek begins now.

shining · 2008-01-16 18:44:55

Every single Arch Linux package uses provisions? That can't be right And all packages don't use versioned dependencies either.

schivmeister · 2008-01-16 18:51:16

hmm yeah you're right now that i think of it..didn't understand what was going on initially. too sad of my failure

cromo · 2008-01-17 00:37:59

Have a look at the reopening request I filed here: http://bugs.archlinux.org/task/9162

Last edited by cromo (2008-01-17 00:39:17)

brebs · 2008-01-17 01:09:49

Show your qt-enhanced PKGBUILD - it's not on AUR.

schivmeister · 2008-01-17 07:09:35

Ok let me clarify my understanding. Basically, if a depends in a PKGBUILD is a specific version eg. depends=('qt>=3.3.8') then if it provides qt, the provision must also follow that syntax as in provides=('qt>=3.3.8') and that's all there is to it..right?

brebs · 2008-01-17 07:14:32

Wrong. See example.

shining · 2008-01-17 07:44:11

I tried to explain why we don't use the same syntax for provisions and dependencies here :
http://bugs.archlinux.org/task/9171#comment23526

However, as I explained above, 3.1.1 will use '=' instead of ' ' for separating the name and the version. But you still won't be able to use '>=', '<=', etc.. Only '='.
This will of course be documented in the man page (man PKGBUILD), but is also already on the wiki :
http://wiki.archlinux.org/index.php/The … guidelines

schivmeister · 2008-01-17 09:05:30

Thanks. So it's exact now. I get it, because this way it makes more sense as normally a package which provides another package above or equal to one version it should conform to that exact version. That way many potential discrepencies can be avoided.

Last edited by schivmeister (2008-01-17 09:10:45)

cromo · 2008-01-17 10:53:39

brebs wrote:

Show your qt-enhanced PKGBUILD - it's not on AUR.

You'll find it here: http://kdemod.ath.cx/svn/branches/kde3/qt-enhanced/
/var/lib/pacman/local/qt-enhanced-3.3.8-16/depends has

%PROVIDES%
qt 3.3.8
just to be sure.

brebs · 2008-01-17 11:03:30

Speculating wildly, maybe you need to reinstall it with pacman 3.1.0-1

cromo · 2008-01-17 11:38:35

It's been installed with 3.1.0

Anyway, poppler's problem seems gone, however I still have similar issue with kdemod-kdelibs:
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (nie udało się usatysfakcjonować zależności)
:: amarok-engine-xine: requires kdelibs>=3.5.7
:: gwenview: requires kdelibs>=3.5.7
:: k3b: requires kdelibs>=3.5.6
:: krename: requires kdelibs>=3.3.0

kdemod-kdelibs's pkgbuild is here: http://kdemod.ath.cx/svn/branches/kde3/kdelibs/PKGBUILD
It seems fine. I reinstalled kdemod-kdelibs package, but it didn't help.

EDIT. OK, removing all of these packages with their dependencies, reinstalling kdemod-kdelibs and installing the packages again helped. This still however seems a weird problem.

Last edited by cromo (2008-01-17 13:17:44)

shining · 2008-01-17 14:25:39

cromo wrote:

EDIT. OK, removing all of these packages with their dependencies, reinstalling kdemod-kdelibs and installing the packages again helped. This still however seems a weird problem.

That's a bit strange indeed. How were you installing the packages? With pacman -U or -S?
If you were using -S, problems are expected, because the tool for building the sync db (repo-add) is broken and doesn't support versioned provisions correctly.
If you were using -U, then I don't know. You could run the testdb tool, to check your system doesn't have broken dependencies.

bionnaki · 2008-01-19 08:22:24

I am also having this trouble, but with the ubuntu packages:

:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
archlinuxfr is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
:: freetype2 conflicts with freetype2-ubuntu. Remove freetype2-ubuntu? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: freetype2: conflicts with freetype2-ubuntu

not exactly sure how to solve this.

brebs · 2008-01-19 08:36:02

First do a quick check:

$  pacman -Qi freetype2-ubuntu | grep Prov
Provides       : freetype2 2.3.5

And a sanity check:

$ grep prov /var/abs/local/freetype2-ubuntu/PKGBUILD 
provides=('freetype2 2.3.5')

Then do a reinstall:

pacman -Rd freetype2-ubuntu
cd /var/abs/local/freetype2-ubuntu
makepkg -fi --asroot

schivmeister · 2008-01-19 11:48:54

Why the extra effort in this case? One could pacman -Sd or pacman -Sud, no?

Arch Linux

#1 2008-01-13 07:21:49

lcd font packages conflicting with original packages

#2 2008-01-13 07:30:01

Re: lcd font packages conflicting with original packages

#3 2008-01-13 09:12:54

Re: lcd font packages conflicting with original packages

#4 2008-01-13 10:08:18

Re: lcd font packages conflicting with original packages

#5 2008-01-13 10:56:14

Re: lcd font packages conflicting with original packages

#6 2008-01-14 10:06:57

Re: lcd font packages conflicting with original packages

#7 2008-01-14 17:02:44

Re: lcd font packages conflicting with original packages

#8 2008-01-15 00:12:05

Re: lcd font packages conflicting with original packages

#9 2008-01-15 11:20:31

Re: lcd font packages conflicting with original packages

#10 2008-01-16 18:21:10

Re: lcd font packages conflicting with original packages

#11 2008-01-16 18:44:55

Re: lcd font packages conflicting with original packages

#12 2008-01-16 18:51:16

Re: lcd font packages conflicting with original packages

#13 2008-01-17 00:37:59

Re: lcd font packages conflicting with original packages

#14 2008-01-17 01:09:49

Re: lcd font packages conflicting with original packages

#15 2008-01-17 07:09:35

Re: lcd font packages conflicting with original packages

#16 2008-01-17 07:14:32

Re: lcd font packages conflicting with original packages

#17 2008-01-17 07:44:11

Re: lcd font packages conflicting with original packages

#18 2008-01-17 09:05:30

Re: lcd font packages conflicting with original packages

#19 2008-01-17 10:53:39

Re: lcd font packages conflicting with original packages

#20 2008-01-17 11:03:30

Re: lcd font packages conflicting with original packages

#21 2008-01-17 11:38:35

Re: lcd font packages conflicting with original packages

#22 2008-01-17 14:25:39

Re: lcd font packages conflicting with original packages

#23 2008-01-19 08:22:24

Re: lcd font packages conflicting with original packages

#24 2008-01-19 08:36:02

Re: lcd font packages conflicting with original packages

#25 2008-01-19 11:48:54

Re: lcd font packages conflicting with original packages

Board footer