[artix-general] icu - run both versions

[Chris Cromer]

First of all tumbleweed has not been around that many years. It showed
up in 2015. Which means that either you are lying, or that you are
mistaken and were using standard opensuse which is not rolling
release. And looking at their packages on their website, they only
have 1 version of libraries. For example in tumbleweed they have ICU
59. And in opensuse 42.3 they only have ICU 52. They do not retain
multiple versions of libraries like you claim. The only time a rolling
distro has more than one version of a library is during a transition,
once the transition is over the old library then gets removed.

As far as how a problem happens with pacman. During a pacman upgrade,
if it finds conflicting files, symlinks, or directories that it does
not manage, it stop the whole upgrade. Basically the system cannot be
upgraded until those conflicts are fixed. Since those files were not
installed by pacman, they can't be touched by pacman causing pacman to
be unable to continue an upgrade. This is a safety feature to prevent
overwriting files that could cause issues or even loss of data. And in
the case of ICU which is a critical library(needed by many packages
including pacman), if they try to fix the conflict by hand and screw
up they could be left with a broken system.

You are free to fix your system in your way, I really don't care what
you do with your system. But do not give your bad advice to others
through public channels, especially since you are not responsible for
fixing the consequences of said advice.

> BTW - yeah what you describe here seems to have failed.  There should
> be a cascade of dependencies and they were broken.
>
> A is udate that should have caused B to be update which should have
> triggered C to be in conflict.
>
> or A is updated and then B and C needs to be updated which should have
> caused a conflict with E and F through B and G and H through C.
>
> If it fails in autoconf it should fail in the binary package.

It failed for a very specific reason. Artix pushed ICU 60 before Arch
Linux pushed ICU 60. In this case we were faster than arch linux to
get the new packages pushed. The packages in arch's repos "extra" and
"community" were not built against ICU 60 yet. The failure here is
that we don't have 100% of arch forked yet. We are still working on
compiling everything, but until the fork is at 100% completion these
problems will happen from time to time. Once arch linux repos are 100%
removed, this should not happen anymore. It's not the chain that is
broken, it isn't the packages that are broken, it's the mixing of
artix and arch linux repos. We already eliminated the "core" repo from
arch linux. Next step is to eliminate "extra". And then sometime in
the distant future eliminate "community". This is not an overnight
process, this will take many months or even years, so stop complaining
because it doesn't help anyone.
Chris Cromer


On Wed, Nov 22, 2017 at 3:43 PM, Ruben Safir <ruben at mrbrklyn.com> wrote:
>
>
>
> 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.
>