Fwd: Re: [artix-general] icu - run both versions

[Ruben Safir]

Chris Cromer


On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir <ruben at mrbrklyn.com> wrote:
> On Wed, Nov 22, 2017 at 12:23:21AM -0300, Chris Cromer wrote:
>> I admit that ICU getting pushed too soon was a problem. But the problem was
>> not because of a broken package. All those other packages needed to be
>> recompiled against the new libs since the ABI is incompatible in the new
>> lib. An unfortunate situation yes, but sometimes these things happen on a
>> rolling release distro.
>>
>
>
> That is incorrect.  I was talking to Rick Moen about this last night and
> the packages are broken and were always broken and will continue to be
> broken.  ICU is not a declared dependency in the packages although they
> are in the source files.

Packages don't have to have "depends" declcared for every single
possible thing in the packages to link against them, it is enough that
they are installed by a dependency of a dependency. So if package C
depends on package B and package A, and package B depends on package
A, it is enough to make package C only depend on package B which forms
a chain of dependencies. There is not need to put package A as
dependency in package C because B will already pull it in as one of
its dependencies. The fact that you don't realize this means that you
have very limited knowledge of how packaging actually works. And
frankly I don't care what "Rick Moen" says, the truth is that those
supposedly broken packages as you call them are linked to ICU when
they were compiled and had to be recompiled to link against the new
version of ICU. They were not "broken", they needed to be updated for
the new ICU version.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hello Chris.  For major libraries this is commonly not necessary as they
are linked as stdc++ ect

It is the smaller libraries that pose this problem and they should be
100% listed with all there dependencies.

Understand, tumbleweed, which is the opensuse rolling release I had for
years rarely if ever had this problem.  Now maybe that is a manpower
issue, and you folks are working your tushas off to get artix up to
speed, but I have SEEN library dependencies cause package management
systems retain libraries in rolling releases, and with Manjaro, that was
an issue with gtk3 where there was no upgrade path without removing
needed packages ... which was a PIA.


But I don't feel compelled, and neither should you, to chose between
100% package management and 100% code base.  Of course, once one goes
off the package management system, its on you, not the artix core
developers or the arch people.  But OTOH, in this instance, what are you
gonna lose?  The benefits are greater than the losses.

Show me how having a spare unmonitored icu library from ARCH presents a
problem and be specific. It over writes NOTHING.  It lives in its own space.