Project

General

Profile

Version conflict between cups-filters and poppler

Time4Tea - about 3 years ago -

Hi!

First off, I would like to point out that when I click on 'Issues', I get a message saying 'Server Busy ...', which doesn't seem to go away. So, I would normally post this as an issue there, but I am not able to do that.

Secondly, there seems to be a conflict with the versions of cups-filters and poppler that are currently in the repository. cups-filters requires poppler=21.01.0-1; however, the current version of poppler seems to be 21.02.0-1. This means I am not able to upgrade either of those packages.

Thanks and regards,

Lee


Replies (11)

Version conflict between cups-filters and poppler - bill-auger - about 3 years ago -

yea i goofed - there will be a replacement soon - thanks for
noticing

RE: Version conflict between cups-filters and poppler - Time4Tea - about 3 years ago -

bill-auger ok, thanks for your reply. I will try it again in another day or two.

RE: Version conflict between cups-filters and poppler - bill-auger - about 3 years ago -

its in the repos now - its just a matter of propagating to your
mirror - that more like hours than days

RE: Version conflict between cups-filters and poppler - bill-auger - about 3 years ago -

the problem with the bug tracker website is fixed now too - thanks for noticing

RE: Version conflict between cups-filters and poppler - Time4Tea - about 3 years ago -

bill-auger ok, awesome! Thanks very much again for fixing those. I can see the poppler version for cups-filters is correct now in the current package database too.

RE: Version conflict between cups-filters and poppler - useresu - about 3 years ago -

This is very frequent -- just happened right now again.

  1. pacman -Su
    [...] error: failed to prepare transaction (could not satisfy dependencies)
    :: installing poppler (21.03.0-1) breaks dependency 'poppler=21.02.0-1' required by cups-filters

Question: what is the correct thing to do, flag the package out of date or file a bug?

RE: Version conflict between cups-filters and poppler - bill-auger - about 3 years ago -

generally, any time pacman gives an error message, that is almost
always a bug

each time 'icu' and 'poppler' are upgraded, there are several
other packages which need to be upgraded also - 'cups-filters'
is one of them - because this will happen probably several times
per year, there are permanent epic tickets open to track
rebuilds - people have already bumped the ticket for poppler
x86_64; so in this case, there is no need for a new bug report

https://labs.parabola.nu/projects/packages/search?q=sticky

RE: Version conflict between cups-filters and poppler - Time4Tea - about 3 years ago -

You know, what I don't get about this whole icu/poppler issue is that, if packages are dependent on very specific versions of these, doesn't that essentially break the whole concept of having dynamic libraries in the first place? As I understand it, part of the point of dynamic libraries is so that, if you update a library then you don't have to simultaneously update all the applications that depend on it.

So, if cups-filters is dependent on a very specific version of poppler, why not statically link them instead to remove the dependency? This combination of very specific version dependencies and dynamic linking seems to be leading to a huge lack of robustness and a lot of maintenance effort. Wouldn't improved stability be worth a small amount of bloat? poppler's installed size is 4MB, icu is 36MB.

RE: Version conflict between cups-filters and poppler - bill-auger - about 3 years ago -

the reason for dynamic libraries is to reduce the size of the
binary (and allowing multiple clients to share the library), and
to allow replacing the dynamic libraries without re-compiling the
main program (and re-compiling the main program without
re-compiling the dynamic libraries) - but that entails the
replacements to be compatible with the same interface, which
may not be the case with different versions of the library

static linking does make maintenance easier; but that is not a
good design goal - if every client of icu did that, then each
one would have a duplicate copy of the library - that 36MB
would be multiplied by the number of clients; and there are many

the goal of a developer should not be to save development time
(another word for that is "laziness"); but instead to reduce
the complexity and memory/CPU footprint of the program - the
attitude of "one more megabyte wont hurt - it saves time (for
me, the developer); and surely all users have computers as fast
and with large memory as mine", if left unchecked, leads to
absurdly bloated and inefficient software; which is most evident
in web software - that is great, if the goal is to roll out as
many new releases as possible (and more bugs) as rapidly as
possible; but it is the exact opposite of the arch/unix
philosophy of reducing (or at least isolating) complexity,
keeping the software lean and specialized (and therefore less
prone to bugs, and able to be run on less-capable hardware) -
that goal is best served, by avoiding to add code which is not absolutely needed, or is duplicating functionality, which is
already present on the system

for example, a bug in a library will affect every client,
regardless of whether it is dynamically of statically linked -
it is most likely that the bug could be fixed, without changing
the library interface - so, if dynamically linked, then the
bug could be fixed in exactly one place, fixing the bug in all
clients

RE: Version conflict between cups-filters and poppler - Time4Tea - about 3 years ago -

bill-auger wrote:

the reason for dynamic libraries is to reduce the size of the
binary (and allowing multiple clients to share the library), and
to allow replacing the dynamic libraries without re-compiling the
main program (and re-compiling the main program without
re-compiling the dynamic libraries) - but that entails the
replacements to be compatible with the same interface, which
may not be the case with different versions of the library

Right, so it seems that second benefit is being nullified in these cases by the specific version requirement. I.e. if the library gets updated, you still have to update all the client applications anyway.

bill-auger wrote:

static linking does make maintenance easier; but that is not a
good design goal - if every client of icu did that, then each
one would have a duplicate copy of the library - that 36MB
would be multiplied by the number of clients; and there are many

I see your point regarding size. I don't know if the system I am on now is 'typical', but I seem to have ~12 applications that depend on icu. So, if static linking added 36MB to each of those, that would be an additional 430MB, which is quite a lot. However, poppler is a lot smaller (4MB) and on my system there are only two packages using it: cups-filters and libreoffice-fresh. So, in that case, it doesn't seem that static linking would lead to a significant amount of bloat.

bill-auger wrote:

the goal of a developer should not be to save development time
(another word for that is "laziness"); but instead to reduce
the complexity and memory/CPU footprint of the program - the
attitude of "one more megabyte wont hurt - it saves time (for
me, the developer); and surely all users have computers as fast
and with large memory as mine", if left unchecked, leads to
absurdly bloated and inefficient software; which is most evident
in web software - that is great, if the goal is to roll out as
many new releases as possible (and more bugs) as rapidly as
possible; but it is the exact opposite of the arch/unix
philosophy of reducing (or at least isolating) complexity,
keeping the software lean and specialized (and therefore less
prone to bugs, and able to be run on less-capable hardware) -
that goal is best served, by avoiding to add code which is not absolutely needed, or is duplicating functionality, which is
already present on the system

I'm not suggesting that static linking should be used as a general policy. Of course not. But, it is there as an option and my point is that it might be worth considering for exceptional cases like poppler/icu, where the dynamic linking seems to be causing persistent problems.

bill-auger wrote:

for example, a bug in a library will affect every client,
regardless of whether it is dynamically of statically linked -
it is most likely that the bug could be fixed, without changing
the library interface - so, if dynamically linked, then the
bug could be fixed in exactly one place, fixing the bug in all
clients

That's a good point about bug maintenance and I can see dynamic linking has a benefit there as well.

    (1-11/11)