libbluray's dependencies: libfreetype.so vs freetype2

Mika79 · 2016-05-09 18:21:34

Hi ppl,

I initially reported a bug to libbluray about the change in dependency, which got rejected without comment. Now in the AUR comments for freetype2-ubuntu I found out that an addition to the AUR package's provides array makes everything behave again, as would changing the dependency in libbluray back to the package instead the .so file.

Is there a reason that now instead of a package a shared object file name is in the dependencies? Is it planned to happen with other dependencies?

Thx

Roken · 2016-05-09 20:25:35

Dunno, but after forcing the issue as suggested in the original thread I've had no problems.

arojas · 2016-05-09 20:33:03

Mika79 wrote:

Is there a reason that now instead of a package a shared object file name is in the dependencies?

It prevents people from breaking their system by doing partial upgrades when there is a soname bump.

Mika79 · 2016-05-09 21:18:52

Oh that actually does sound good. Thank you for shedding light on it.

Jristz · 2016-05-11 03:47:34

arojas wrote:

Mika79 wrote:
Is there a reason that now instead of a package a shared object file name is in the dependencies?
It prevents people from breaking their system by doing partial upgrades when there is a soname bump.

but partial upgrades are unduported then these ones runing half-upgraded system should full upgrade them to get support, there no point in changing thinks to make easy for unsuported systems to smotly upgrade that like giving somekind support to half-upgraded system keeping the sonames corrects.

But for the other part the only reason that this could be implemented is to prevent upgrades from missync servers.

jasonwryan · 2016-05-11 03:51:26

Jristz wrote:

arojas wrote:
Mika79 wrote:
Is there a reason that now instead of a package a shared object file name is in the dependencies?
It prevents people from breaking their system by doing partial upgrades when there is a soname bump.
but partial upgrades are unduported then these ones runing half-upgraded system should full upgrade them to get support, there no point in changing thinks to make easy for unsuported systems to smotly upgrade that like giving somekind support to half-upgraded system keeping the sonames corrects.
But for the other part the only reason that this could be implemented is to prevent upgrades from missync servers.

Good lord. Even for you this is unintelligble. He isn't saying it makes it easier....

eschwartz · 2016-05-11 05:07:37

I was under the impression that the Arch Developers only did this in extremely rare cases. Like bash depending on libncursesw.so -- this was supposedly only because a broken bash prevents you from even logging into a shell to fix it (necessitating the use of installation media to perform repairs), and it is rather hard on someone to render their system completely unbootable just because they made a single mistake.

What is the justification for preventing libbluray from breaking by making it depend on a provides=$soname of freetype2 -- aren't people who break their system with partial updates expected to fix the problem manually from a tty or rescue shell or whatever?

arojas · 2016-05-11 06:28:30

Eschwartz wrote:

What is the justification for preventing libbluray from breaking by making it depend on a provides=$soname of freetype2 -- aren't people who break their system with partial updates expected to fix the problem manually from a tty or rescue shell or whatever?

I completely agree - Arch users should be responsible for the breakage they cause by doing partial upgrades. And it's not like it prevents clueless users form filing bug reports, as we've seen in this case (https://bugs.archlinux.org/task/49180) I'ts ultimately the maintainer's decision, AFAIK there's only one dev doing this for now.

Mika79 · 2016-05-11 23:10:54

Oh Im sorry I made a likewise clueless bugreport too. Maybe its helpful for the interested to read how I came to it.

Im new to Arch Linux, new to this community, but not really new to Linux. Though my resources and neccesities fixed me on having another System as only boot System in the past, and I was using Linux solely in virtual machines. Dealing with breakage in a throw away container is primitivly easy. Now Im happily having Linux as my main OS.

After reading along here it seemed to be to consense to 'educate' users to report bugs instead of using 'hacks' and remain silent. That encoruaged me to try likewise.

I tried to analyse why my system did not do what I want it to do, I took a look at the seemingly offending package and saw something in it that didn't seem to be documented in the PKGBUILD docs (the possibility of sonames is in the manpage, I dont see it anywhere else, but the implications and behaviours aren't intuitive or documented explicitly), something that caused the 'wrong' package beeing pulled, and changing it back to what it was and what was working two PKGBUILD versions of libbluray ago would cure the issue. So I reasoned along that just by a probable oversight or something libbluray was 'broken' when using a different package prividing freetype2 then the base version, and thus concluded it might be helpful to report it as bug.

Now I maybe shouldn't have stopped reasoning there, but I did.

I didn't see other bugreports about it, I didn't see the AUR comments in the package that was hinting at the real culprit. I didn't use all search functions under the sun, but tried some. The forum search f.e. was giving me back resoluts of like 75 page threads without a clue where in the thread the words I searched were mentioned, and f.e. google didn't spit out tangible info like the closed bug reports or something in the forum, mailinglist archives or whatever.

So I reported the bug, it was gone like, immediatly, without further hints besides that its not a bug. Then by mere chance I read the AUR comments and knew why it didn't work, and came back here to ask whats the rationale for a soname vs a package dependency.

I do think the rationale to have sonames as dependencies is good. Maybe not per se in libbluray, but generally. I found some devs discussing it a few years back after specifically searching for it with the knowlegde arojas gave on it, and I think I understand its current and actual behaviour now.

But I don't think that the general tone is good. I tryed to help, not to cause other ppl to do useless cleanup work in the bugreport tool. And I obviously wasn't the only one analysing the 'breakage', not the only one reporting it as a bug, I still don't know what 'original thread' could be meant where I could have learned all that before jumping into the waters and creating a bugreport.

So to me it looks like this: why do people not report bugs? Its not because they need more education towards reporting bugs instead of applying hacky things themselves and remain silent, its because chances are they have not seen the whole picture and someone knowledgable puts them on their place face down, even leaving them behind clueless about the real thing (the bugreport tool f.e. has the ability to show comments about why something is not a bug, if they were written it is). Noone likes that right? In the end some kind of people ends up irritated, reacting unreasonable, airing their bad feelings talking nonsense in other threads and themas, whatever. Surely leading to more work for mods if things go south further.

It might be very good to review a few things about how to handle users, so it ends up beeing positivly instead of negativly for all parties. I cannot imagine devs are happy if they come to think of lots of users like me as dummies that don't know blahr and don't search for clues beforehand, and I don't think users are happy if the environment around a great thing like Arch Linux feels so hostile, and I assure you it does (surely, less because thats what the mods and devs want, but because a feedback loop towards the negative end makes it so).

Anyways Ill keep trying to ignore that percieved hostility, and will try to help with my humble bits of knowlegde where it might help. So this will maybe lead to more closed bugreports, or seemingly numb threads here, but we can all live with that, right?

If noone objects, and noone does before me, and if I have the rights to do, I will add the description of the possibility for sonames and its behaviour as I understand it to the wiki pages relating PKGBUILD in a few days, alright? That might help other users understand a future change of a different package and help themselves.

ngoonee · 2016-05-12 02:07:14

No-one will object to updated documentation. As to the rest of your wall of text, the most important thing is 'perceived hostility'. Devs/TUs/whoever has no control over your perception, and the nature of Arch (close to upstream, fast-moving) means its easy to get lost and frustrated.

That's fine, because most contributors (and that's all devs/TUs/mods really are, volunteer contributors) aren't trying to make Arch popular or 'market' it. They're not even trying to encourage bug reports per se (that's just more work, and only useful if done properly), just to encourage quality bug reports. Likewise hacks aren't discouraged per se, the users should just understand what they do and the risk they entail. Great power -> great responsibility etc. etc.

Scimmia · 2016-05-12 03:15:23

OK, enough. Would it have helped at all if I simply said "Unsupported packages are unsupported" when I closed the report? I kind of thought this was a given and is at the top of every page in the bug tracker. If you're using packages outside of the repos, they're your responsibility.

Lone_Wolf · 2016-05-12 14:22:58

I do have the feeling many users don't see the line between supported and unsupported packages clearly.

Maybe the pacman conflict error message could be changed to make that clearer ?

It could work like this :

A and B conflict

A & B are from official repos > conflict between 2 supported packages, check news, forum & bugreports.

A is from official repos, B isn't > there's a conflict between supported package A and unsupported package B. Solving these kind of problems is your responsibility.

A & B are both not from official repos > conflict between 2 unsupported packages. solving this kind of problem is your responsibility.

eschwartz · 2016-05-12 14:53:59

Eschwartz wrote:

I was under the impression that the Arch Developers only did this in extremely rare cases. Like bash depending on libncursesw.so -- this was supposedly only because a broken bash prevents you from even logging into a shell to fix it (necessitating the use of installation media to perform repairs), and it is rather hard on someone to render their system completely unbootable just because they made a single mistake.

... although it turns out I was actually thinking of readline, cf. this bug report: https://bugs.archlinux.org/task/15566
Of course it doesn't matter which of two packages breaks bash, the theory is the same.

Scimmia · 2016-05-12 15:03:11

Lone_Wolf wrote:

Maybe the pacman conflict error message could be changed to make that clearer ?

Pacman has no concept of official repos or unsupported packages. Remember, pacman is not limited to Arch.

Arch Linux

#1 2016-05-09 18:21:34

libbluray's dependencies: libfreetype.so vs freetype2

#2 2016-05-09 20:25:35

Re: libbluray's dependencies: libfreetype.so vs freetype2

#3 2016-05-09 20:33:03

Re: libbluray's dependencies: libfreetype.so vs freetype2

#4 2016-05-09 21:18:52

Re: libbluray's dependencies: libfreetype.so vs freetype2

#5 2016-05-11 03:47:34

Re: libbluray's dependencies: libfreetype.so vs freetype2

#6 2016-05-11 03:51:26

Re: libbluray's dependencies: libfreetype.so vs freetype2

#7 2016-05-11 05:07:37

Re: libbluray's dependencies: libfreetype.so vs freetype2

#8 2016-05-11 06:28:30

Re: libbluray's dependencies: libfreetype.so vs freetype2

#9 2016-05-11 23:10:54

Re: libbluray's dependencies: libfreetype.so vs freetype2

#10 2016-05-12 02:07:14

Re: libbluray's dependencies: libfreetype.so vs freetype2

#11 2016-05-12 03:15:23

Re: libbluray's dependencies: libfreetype.so vs freetype2

#12 2016-05-12 14:22:58

Re: libbluray's dependencies: libfreetype.so vs freetype2

#13 2016-05-12 14:53:59

Re: libbluray's dependencies: libfreetype.so vs freetype2

#14 2016-05-12 15:03:11

Re: libbluray's dependencies: libfreetype.so vs freetype2

Board footer