Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Update of libpsl in system-testing repo (Read 3046 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Update of libpsl in system-testing repo

Reply #15 –
Well whatever you do, don't update Artix testing without updating libidn2 and libpsl. You'll have a bad time since pacman will search for version of libicuuc.so.59 (the old version) instead of libicuuc.so.60. I just did some more testing and that was what caused my library error earlier. Hopefully that libidn2 package will find its way into system-testing soon.

Re: Update of libpsl in system-testing repo

Reply #16 –
Robin   I think you took it out of context, and with one liner instructions I do not blame you.
As dudemg says, running testing is just as risky as core, as everything ending up in core has gone through testing.
A new package being in testing in the morning and in stable in the evening is what Arch calls cutting edge.  Ok debian is slow and conservative but I call this hemorrhaging edge.  Who did the testing?  Did I do it 15hrs away while you are in stable and never saw it coming?

What I think @nous implied was that at times you may have to activate arch core and testing to snatch something artix hasn't had time to hack and return to artix.  Meaning you comment out core and testing and reupdate.

You upgrade ONCE with core, maybe testing too if you are not very lucky, and I can warranty you will be broken.  And this is getting worse and worse with systemd.  Now much of QT stuff pull systemd dependencies, before we know it you will need systemd to run vi or nano.

Re: Update of libpsl in system-testing repo

Reply #17 –
Quote from: robin0800 – on
@nous said "If you use Artix testing repos, you should also use Arch testing repo" which to be honest I don't really like. I wish in cases like this assuming we need  libpsl and it now has a dependency of libidn2 then it would be nice if this could be added to one of our repo's in a timely manner. There does not appear to be too many of them so perhaps not a very big job?

We use our testing repos to, well, test the packages for functionality and breakage. We can't possibly remember by heart every single dependence of a package nor which repo they're in. When libpsl in [system-testing] revealed its new libidn2 dependency, we put it in our updated package import list and is scheduled for build.

What I meant to say with my first post is that using testing repos isn't for the faint of heart. People should be both able to resolve problems and kindly report them to the forum, or even better on our github repositories.

Actually, this should be front page material: it's better to open issues on Github because the devs can see them more easily and act on them; a post in the forum can be easily overlooked.