Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#13120 closed bug (fixed)

pkgman full-sync error

Reported by: michel Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

in hrev 50789 and up

~> pkgman full-sync

Encountered problems:
problem 1: package lcms_x86-2.5-1 requires lib:libpng_x86>=15.12.0, but none of the providers can be installed
  solution 1:
    - keep libpng_x86-1.5.25-1 from excluded repository
  solution 2:
    - allow deinstallation of qpdfview_x86-0.4.13-3
    - allow deinstallation of lcms_x86-2.5-1

This looks like a typo in the requires{} section of lcms. changing 15 to 1.5 should fix it.

Change History (10)

comment:1 by korli, 8 years ago

Owner: changed from nobody to pulkomandy
Status: newassigned

comment:2 by pulkomandy, 8 years ago

Not a typo, the version of the lib is indeed 15.something. The problem is that the libpng recipe has somehow lost the "libpng" provide and now provides only "libpng15" (or "libpng16" for the latest version). This is more correct, but all old packages need to be adjusted. I have started to upload new ones, but I didn't have time to finish before my christmas break. Please list packages you have issues with, and I'll try to replace them promptly.

comment:3 by vidrep, 8 years ago

BePDF is affected.

comment:4 by korli, 8 years ago

This problem is unfortunate and a bit ridiculous in my opinion. What happens with the packages with the failing dependency in external repositories ? What's the cost of restoring working libpng packages ?

comment:5 by pulkomandy, 8 years ago

After a little history tracking:

I had removed the libpng provides in the 1.16.20 recipe. This had apparently never been uploaded to the repo, and stayed in the recipe only. I used this recipe with the libpng provide removed when creating the release repo. I see that this change was ignored when making later versions of the recipe, too.

The removal seems correct: there is no libpng.so* at all in the package, and as far as I can see, there hasn't been for a long time. So the packages pretend to provide "libpng.so", but in fact they don't. This could lead to more trouble later on.

I think it makes sense to fix this now, rather than later. Or, if we want to have a plain "libpng.so", we should not only add it to the "provides", but also make the packages actually include the library. Otherwise, this makes no sense.

comment:6 by korli, 8 years ago

What makes no sense is to alienate our userbase with broken packages and inconsistent repositories. The change with new libpng hpkgs should have been reverted because it broke the build, because it breaks possibly hpkgs installation for external repositories. We can make such a change for libpng17 anyway, I don't see the need for a hurry.

comment:7 by michel, 8 years ago

qt5_x86 is showing the libpng problem in hrev 50817

Last edited 8 years ago by michel (previous) (diff)

comment:8 by michel, 8 years ago

sdl_image is showing the libpng problem on hrev 50837

comment:9 by pulkomandy, 8 years ago

Resolution: fixed
Status: assignedclosed

I think most packages have been fixed now. If you still have problems, please provide the exact version of the package you can't install.

in reply to:  9 comment:10 by Giova84, 8 years ago

Replying to pulkomandy:

I think most packages have been fixed now

I encountered a similar issue with libpng, 8 days ago: ticket:13408 So, as you stated, such packages has been fixed, now?

Note: See TracTickets for help on using tickets.