[artix-general] icu - run both versions

[Ruben Safir]

On Wed, Nov 22, 2017 at 06:12:20PM -0300, Chris Cromer wrote:
> First of all tumbleweed has not been around that many years. It showed
> up in 2015. 

FWIW:
For the opensuse site:

On November 4th 2014 the Tumbleweed rolling release and Factory rolling
release merged, leaving the single openSUSE Tumbleweed rolling release
we have today

Its been around way before 2014, but don't ask me the complete history.




> 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.

I only have one opensuse server left with the conversions to artix

/usr/lib/gcc/i586-suse-linux/4.8/libstdc++.a
/usr/lib/gcc/i586-suse-linux/4.8/libstdc++.so
/usr/lib/gcc/i586-suse-linux/4.9/libstdc++.a
/usr/lib/gcc/i586-suse-linux/4.9/libstdc++.so

I'm actually suprised how clean it is.

> 
> 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. 

That doesn't seem to stop it from rewriting my mysql configuation
repeatedly.  I would need to have a clearer understanding of the rules
because at the moment, my workstation is a chock ful of such things,
including multiple perl, pythons, netbeans, and other non-pacman aps and
libraries and pacman doesn't seem to care less.  It would be somewhat
helpful if it did do that.  Then it would stop rewriting my netbeans
configs.

[www3 ~]# pacman -S icu
warning: icu-60.1-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) icu-60.1-1

Total Installed Size:  34.98 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring
[####################################################] 100%
(1/1) checking package integrity
[####################################################] 100%
(1/1) loading package files
[####################################################] 100%
(1/1) checking for file conflicts
[####################################################] 100%
(1/1) checking available disk space
[####################################################] 100%
:: Processing package changes...
(1/1) reinstalling icu                      


[www3 ~]# ls -al /usr/lib/libicu*
lrwxrwxrwx 1 root root       18 Nov 13 05:40 /usr/lib/libicudata.so ->
libicudata.so.60.1
lrwxrwxrwx 1 root root       18 Aug 22 05:51 /usr/lib/libicudata.so.59
-> libicudata.so.59.1
-rwxr-xr-x 1 root root 26292888 Aug 22 05:51 /usr/lib/libicudata.so.59.1
lrwxrwxrwx 1 root root       18 Nov 13 05:40 /usr/lib/libicudata.so.60
-> libicudata.so.60.1
-rwxr-xr-x 1 root root 26825368 Nov 13 05:40 /usr/lib/libicudata.so.60.1
lrwxrwxrwx 1 root root       18 Nov 13 05:40 /usr/lib/libicui18n.so ->
libicui18n.so.60.1
lrwxrwxrwx 1 root root       18 Aug 22 05:51 /usr/lib/libicui18n.so.59
-> libicui18n.so.59.1
-rwxr-xr-x 1 root root  2599040 Aug 22 05:51 /usr/lib/libicui18n.so.59.1
lrwxrwxrwx 1 root root       18 Nov 13 05:40 /usr/lib/libicui18n.so.60
-> libicui18n.so.60.1
-rwxr-xr-x 1 root root  2762816 Nov 13 05:40 /usr/lib/libicui18n.so.60.1
lrwxrwxrwx 1 root root       16 Nov 13 05:40 /usr/lib/libicuio.so ->
libicuio.so.60.1
lrwxrwxrwx 1 root root       16 Aug 22 05:51 /usr/lib/libicuio.so.59 ->
libicuio.so.59.1
-rwxr-xr-x 1 root root    55056 Aug 22 05:51 /usr/lib/libicuio.so.59.1
lrwxrwxrwx 1 root root       16 Nov 13 05:40 /usr/lib/libicuio.so.60 ->
libicuio.so.60.1
-rwxr-xr-x 1 root root    55056 Nov 13 05:40 /usr/lib/libicuio.so.60.1
lrwxrwxrwx 1 root root       18 Nov 13 05:40 /usr/lib/libicutest.so ->
libicutest.so.60.1
lrwxrwxrwx 1 root root       18 Aug 22 05:51 /usr/lib/libicutest.so.59
-> libicutest.so.59.1
-rwxr-xr-x 1 root root    64616 Aug 22 05:51 /usr/lib/libicutest.so.59.1
lrwxrwxrwx 1 root root       18 Nov 13 05:40 /usr/lib/libicutest.so.60
-> libicutest.so.60.1
-rwxr-xr-x 1 root root    64616 Nov 13 05:40 /usr/lib/libicutest.so.60.1
lrwxrwxrwx 1 root root       16 Nov 13 05:40 /usr/lib/libicutu.so ->
libicutu.so.60.1
lrwxrwxrwx 1 root root       16 Aug 22 05:51 /usr/lib/libicutu.so.59 ->
libicutu.so.59.1
-rwxr-xr-x 1 root root   203288 Aug 22 05:51 /usr/lib/libicutu.so.59.1
lrwxrwxrwx 1 root root       16 Nov 13 05:40 /usr/lib/libicutu.so.60 ->
libicutu.so.60.1
-rwxr-xr-x 1 root root   203288 Nov 13 05:40 /usr/lib/libicutu.so.60.1
lrwxrwxrwx 1 root root       16 Nov 13 05:40 /usr/lib/libicuuc.so ->
libicuuc.so.60.1
lrwxrwxrwx 1 root root       16 Aug 22 05:51 /usr/lib/libicuuc.so.59 ->
libicuuc.so.59.1
-rwxr-xr-x 1 root root  1763088 Aug 22 05:51 /usr/lib/libicuuc.so.59.1
lrwxrwxrwx 1 root root       16 Nov 13 05:40 /usr/lib/libicuuc.so.60 ->
libicuuc.so.60.1
-rwxr-xr-x 1 root root  1799952 Nov 13 05:40 /usr/lib/libicuuc.so.60.1


> Basically the system cannot be
> upgraded until those conflicts are fixed. 

Well, it hasn't yet discovered them then.

> 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.
>

Nous, you do know that people WILL try to fix their boxes when they are
broken and rational information is better than the clueless pulling
ideas out of umbuntu's forum and break there boxes.  You also are aware
that breaking systems is not the exclussive domain of people downloading
source code.  Package management systems are very capable of doing this
on a routine basis.  There simply is no wall of perfection and a great
and powerful OZ behind the package maintainers.  There is just bright,
honest, hard working people doing their level best without enough
resources

You don't want to encourage these guys to flood the forum complaining
that the artix developers aren't moving fast enough and are sloppy.
This is a result of not just the dark side of human nature, but also by
creating an expectation of dependency.


> 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. 

Yeah that should have caused a whole cascade of pacman errors and
warning right there... however...

> 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. 

That is really cool to hear!  Do we have the manpwoer to pull that off
over the long haul?  Can I help?


Package management problems are common and often on ALL distros,
although some are better than others.

You are never going to put an end to them and there will always be
programs and projects, many on github now, which are outside of normal
package channels, so one needs to learn to use the system and tell folks
they are rescricted blindly to the package manager for the rest of their
lives is counter productive and violates rule one of Free Software,
which is that we empower the end user and strengthen them with
knowledge.

I'll make you a gentlemans bet right now that for Junior Cheese cakes
that in 5 years that iuc59 sitting on the system will cause ZERO admin
problems for pacman.

> 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.

There hasn't been a __single word__ of complaint about the project  by me ... kid :)

This has been the best thing I've been able to evaluate which is currently developing.


> 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.
> >

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive 
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013