MESSAGE
| DATE | 2017-11-22 |
| FROM | artoo
|
| SUBJECT | Re: [Hangout - NYLXS] [artix-general] icu - run both versions
|
To explain further,
we have not and had not broken icu packages.
What we had, is that arch linux had some of their rebuild in their
testing repo, which wasn't listed by default in pacman.conf as commented.
I fixed that, pacman got a rebuild with updated pacman.conf after icu
was bumped and built. All correct.
The problems occurred, if people had our testing repos enabled, but not
the arch testing repo.
since we are still in the process to have a complet set of build
dependencies in our repos, such things may happen, until we can disable
arch repos one by one and remove the arch repo dependency.
On 22.11.2017 22:12, Chris Cromer wrote:
> 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 wrote:
>>
>>
>> Chris Cromer
>>
>>
>> On Wed, Nov 22, 2017 at 12:52 PM, Ruben Safir 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.
>>
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
