Skip to main content ↑ ↓
Topic: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction. (Read 2743 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction.

Reply #15 –
The original issue seems to have been resolved; I find the *5 variants now also in the Artix repositories (and have replaces-entries for the plain-named packages), together with the plain-named packages with the same name.

It would have been helpful if this availability would have been posted here.

Thanks for keeping up and things running!, 
regards!

Re: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction.

Reply #16 –
Quote from: gripped – on
Quote from: onekk – on
Good politics, but you should supply more packages in arch repos.
You make a fair point.
Partially it's an issue of clarity. It should be made clear on the website / wiki / faq that Artix is not suitable for beginners to Linux UNLESS they will be happy with the reduced set of packages (as compared to Arch) available.
So if all you use the computer for is browsing and some word processing it's fine even as a beginner.
....


It is not to make Artix suitable for all needs, but as example in one of my post, I have posted some packages that are needed to make simple things:


Generic packages, that should be supplied by Artix, as they are needed to use Artix without a Desktop Environment:

numlockx
beep


Packages I need to use openbox in a decent way, at least tint2 is wide used enough to be supplid by Artix:

tint2
jgmenu


To use  FreecAD, I had to install these packages:

coin
freeimage
med-openmpi
hdf5-openmpi
jxrlib
libspnav
opencascade
python-pivy
soqt


Yesterday to make my printer work, I've had to add thsi package:
sane-airscan


And then I have loaded some packages in rpm format to make my new printer work, a Brother laser MFD.

But today, I 've found a way to use all the facilities of the printer without loading the manufacturer package, it has been a matter to read something about in the Gentoo wiki:

https://wiki.gentoo.org/wiki/Driverless_printing

Code: [Select]
sudo lpadmin -p L2710 -E -v ipp://192.168.0.102/ipp -m everywhere

It should be sufficient to use it with CUPS with standard drivers.

Both scanning and printing seems to work.

So in general I had not much problems.

I second an alternative way to make some things better in Artix, as done in some other distros, (and As I've partially done) supply a set of scripts that permit to load specific packages from Arch repos, (or other repo) and to check when they are updated to make things easy, leaving to the user the burden to periodically run them if the "few" packages will became broken.

But this need probably as told by other another topics, let me know if something will be opened, (quoting me to trigger an alert supplied by the forum webpage.)

As usual this is to "make Artix better",  as developers are doing a very good jobs.

Kind Regards

Carlo D.



Re: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction.

Reply #17 –
In my opinion most of these issues regarding how beginner-friendly Artix is really stem from it being rolling-release. You need to be able to do package management, identify problems, downgrade them and "IgnorePkg" them on occasion. All Arch based distros have this requirement. With the Debian based model of no major upgrades until a new Debian release, you typically get hit with multiple breakages when you do finally upgrade to the next version, rather than dealing with them one at a time. Artix might have problems sometimes that don't exist in Arch but the slight delay in package updates allows Arch problems to be kept out, there have been numerous occasions when Artix users have been saved from Arch bugs.
 I really like being able to use the Arch repos and AUR, for me it solves problems and very rarely creates any. There are some things I need from Arch, but why should Artix dev's have to spend time packaging them if it's just me who uses them? And if they have more free time then they might be able to do things like add these "5" packages sooner!  ;D

Re: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction.

Reply #18 –
Quote from: ####### – on
In my opinion most of these issues regarding how beginner-friendly Artix is really stem from it being rolling-release. You need to be able to do package management, identify problems, downgrade them and "IgnorePkg" them on occasion. All Arch based distros have this requirement. With the Debian based model of no major upgrades until a new Debian release, you typically get hit with multiple breakages when you do finally upgrade to the next version, rather than dealing with them one at a time. Artix might have problems sometimes that don't exist in Arch but the slight delay in package updates allows Arch problems to be kept out, there have been numerous occasions when Artix users have been saved from Arch bugs.
 I really like being able to use the Arch repos and AUR, for me it solves problems and very rarely creates any. There are some things I need from Arch, but why should Artix dev's have to spend time packaging them if it's just me who uses them? And if they have more free time then they might be able to do things like add these "5" packages sooner!  ;D

IMHO mostly adapting an Arch package to Artix is simply putting it in the "Artix Building system",  if systemd is not in dependencies probably it is a matter of copying a couple of file and make the "Building system" do the build.

But if versions are handpicked to do some sort of triage about bugs, probably I'm wrong.

numlockx as example is not a big problem, but if you use as example lightdm it is needed to have numpad active on startup, it is strange to not having it by default.

I have created a script that take care of feeding packages from arch to a local repo, to have FreeCAD dependencies satisfied, but it lacks of some automation, as I don't know every aspect of pacman and repositories, it is mostly a cut, modify and paste from various sources around the net and a couple of answers.

I'm satisfied with this setup as my past experiences activating arch repo and letting pacman do the work, have created in time, probably due to version mismatch a nightmare to maintain, so As i have a second artix install, I have rebuild from scratch "root directory" and kept home ()I have put them in separate partitions, so it is easy to do the change.

Arch is for advanced users, but not for hackers, so it is perfectly manageable even by users slightly after "newbie level", having used it intermittently during years, I have used Debian, Ubuntu and derivatives (mostly Mint) then Devuan and then Artix, I haven't noted the date when I've started to use Linux, but it is more than 20 years that I use Linux

Re: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction.

Reply #19 –
This thread has gone a little off the rails at this point. But on the topic of bringing in new packages, I became a package maintainer because I wanted Artix to be a viable distro for me. Of course I could enable Arch repos or build packages manually, but especially in the latter case I feel that effort is wasted if other users can't benefit from it.

I also want to help fill in those gaps for y'all as well. I can't possibly know what packages everyone uses unless it's brought up. When I see requests in here, I usually import a few. At least the low hanging fruit.

Quote from: onekk – on
IMHO mostly adapting an Arch package to Artix is simply putting it in the "Artix Building system",  if systemd is not in dependencies probably it is a matter of copying a couple of file and make the "Building system" do the build.

You are mostly correct. As a fork of Arch, we get to benefit from a lot of their maintainers' heavy lifting. There are cases where things need to be tweaked to build in the pipeline as well as builds that fail because Arch maintainers build packages on their own computers. But for the most part, bringing in upstream changes is trivial.

What's not trivial are the updates that involve rebuilding large numbers of packages against an updated dependency or, in the case of this thread, dependencies getting mass-renamed. Coordination between team members is required and, of course, we're all doing this in our free time. On its own, that's not a problem. The updates come out when they're ready. But for the user that runs pacman -Syu every day with Arch repos enabled... yeah, that's going to be a problem.

What I'm trying to say without rehashing what's already been said is even after a package is imported, the maintenance of said package is an ongoing thing that isn't always insignificant.

I've added beep, numlockx, and tint2.

Re: Unresolvable Package Conflicts Detected. Failed to Prepare Transaction.

Reply #20 –
Note: 
In the updated *5 packages, the provides-entries which mention the generic names are gone:

world/ki18n5 version 5.111.0-1: 
Provides        : None

Installed previous version local/ki18n5 version 5.110.0-1: 
Provides        : ki18n=5.110.0

Regards!