Solve the use of unknown package managers by use a meta-package manger and aliasing

[FruityWelsh]

One benefit of this approach is that guides for other distros may still work on your without user interpretation of the package manager cmds. The downside is that without a dictionary of package naming from one distro to another may lead to bugs.

Bedrocks Linux's pmm is the best example of this, though of course built to work with actual packages from each distribution (along with the rest of the bedrock structure).

I think this combined with a reasonable dictionary lookup between the top five distros would get pretty far for usability. Of course, the other added use could be including distro-less repos like flatpack with a single packagemanager.

Another one that looks promising is pacapt though it only solves it one way.

[Fuzzi99]

package-kitexists and it's job is to interface between the systems package manager and discover/GNOME software/others it's called in the command line with pkcon

[magnus-ISU]

I don't think this is a good idea. The problem is that you have to get new guides to use your meta-package manager, and then you have to add lots of complexity to your meta-package manager to interpret package names that are slightly different on differing distros. And all development effort on this meta-package manager is wasted time, because it doesn't actually provide new functionality over old package managers, in fact it must cater to the least powerful package manager out there.

If we're going to change every article anyway, make them use flatpak

[glibg10b]

@magnus-ISU And the biggest problem with a meta-package manager would be compatibility. Every package manager executes commands slightly differently, handles dependencies slightly differently, lacks and has some functionality that others don't, and prints different errors. It will never work :(

If all distros are able to work on support for a meta-package manager, then they should also all be able to work on supporting the same, standalone package manager.

Of course, that's never gonna happen because different distros have different philosophies and their package managers reflect that.

[magnus-ISU]

Exactly, but we can install flatpaks on every distro, so guides should use that when available. The package in question, steam, has a good flatpak.

[andike82]

is it possible to just do an alias?

alias apt install=pacman -S

or

alias apt install=echo Use "pacman - S" instead.

or something like this?

[realmazharhussain]

I think a good solution would be to put simple bash scripts in place of apt, dpkg, yum, etc. which print out messages like this when they are run

$ sudo apt install vlc
Warning! This distro does not support 'apt'. Use 'pacman' instead.
For example, run 'sudo pacman -S vlc' to install vlc.
$

Such scripts should be created not just for apt but also for 2 to 3 of other most popular package managers.

These scripts should come preinstalled.

So, users following online guides would unknowingly execute these scripts and get to know that package manager on their distro is something other than what they just typed and for simple tasks, exactly what to type to do the same thing using package manager of the current distribution.

[Charadon]

In my opinion, a simple bash function can easily solve this:

function apt() {
    if [ -x /usr/bin/apt ];
    then
        /usr/bin/apt $@
    else
        echo "pacman is the system's default package manager."
    fi
}

Advantage of this, is that if someone, for whatever reason has apt installed, it'll still work. While if they don't have it installed, or if it's just not set as executable, it will display an error suggesting they use pacman/whatever distro's package maager instead.

[magnus-ISU]

@andike82 @Charadon I do not like these solutions, which already exist in Garuda Linux, because they will almost never actually be executed by a user. How often does a user ever run apt install something. You run sudo apt install something which ignores exported bash functions and aliases and will give the stupid 'command not found' error.

You must use an actual script as @realmazharhussain says. This has the benefits that it can be installed and removed by the package manager too, since it isn't modifying any files in a users $HOME. As I said in #10, I created pacman-noob-tutorial for this, but it is not production-ready and is arch-specific, similar scripts should be made for debian, ubuntu, etc distros I think.

The only disadvantage is that if the user installs apt, I think there is an AUR package that contains it for example, you will have a conflict. However, again, since an installed program can be managed by the package manager, you can set those packages up to properly conflict in a way a bash alias cannot be.

[magnus-ISU]

Also, if you disagree with me and think that a meta-package manager is a good solution, pacapt already exists so look into it.

[FruityWelsh]

I don't think this is a good idea. The problem is that you have to get new guides to use your meta-package manager, and then you have to add lots of complexity to your meta-package manager to interpret package names that are slightly different on differing distros. And all development effort on this meta-package manager is wasted time, because it doesn't actually provide new functionality over old package managers, in fact it must cater to the least powerful package manager out there.

If we're going to change every article anyway, make them use flatpak

I like flatpak, but I don't think it is the solution to all installation, there are benefits to other types of installations (space savings, easy of administration, better performance through compilation at install time, etc).

In my vision, it only has to cater to the system's package manager. The goal isn't to give full apt style package management, only to give a cli compatible with apt commands (as an example).

Basically, it's separating the CLI from the backend as much as possible so that you can use different CLI frontend interchangeably. (Like I said pmm seems to do this pretty well) The tricky part is as you mentioned in the naming scheme of the packages and their dependencies. I personally don't see an easy way to do the latter, but the former is just a dictionary lookup , no?

[Charadon]

@andike82 @Charadon I do not like these solutions, which already exist in Garuda Linux, because they will almost never actually be executed by a user. How often does a user ever run apt install something. You run sudo apt install something which ignores exported bash functions and aliases and will give the stupid 'command not found' error.

Putting that function in /etc/profile.d should allow sudo to use it, shouldn't it? I'll have to test that.

[magnus-ISU]

Putting it in /etc/profile.d would indeed probably work, but wouldn't work if the user's shell is not POSIX (ion or fish) - I still think there is no reason to not use an actual executable script for this.

Still, it is much better than a user's bashrc. Package managers can install to /etc/ for one.

[tjkrobertson]

@andike82 @Charadon I do not like these solutions, which already exist in Garuda Linux, because they will almost never actually be executed by a user. How often does a user ever run apt install something. You run sudo apt install something which ignores exported bash functions and aliases and will give the stupid 'command not found' error.

You must use an actual script as @realmazharhussain says. This has the benefits that it can be installed and removed by the package manager too, since it isn't modifying any files in a users $HOME. As I said in #10, I created pacman-noob-tutorial for this, but it is not production-ready and is arch-specific, similar scripts should be made for debian, ubuntu, etc distros I think.

The only disadvantage is that if the user installs apt, I think there is an AUR package that contains it for example, you will have a conflict. However, again, since an installed program can be managed by the package manager, you can set those packages up to properly conflict in a way a bash alias cannot be.

How is "command not found" a "stupid" answer and not exactly what's happening on the system?

In no way is pacman responsible for knowing about all the other package managers. Are we going to force apt to have similar aliases? What about dnf?

As another commenter mentioned, this is the job of PackageKit. Leave the actual package managers out of it.

[Charadon]

Putting it in /etc/profile.d would indeed probably work, but wouldn't work if the user's shell is not POSIX (ion or fish) - I still think there is no reason to not use an actual executable script for this.

Still, it is much better than a user's bashrc. Package managers can install to /etc/ for one.

Honestly, if a user changes their shell to fish from bash, doesn't that imply they have at least a bit of compentence with linux? Atleast to the knowledge of knowing that distros have different package managers. After all, fish is almost never default, and you have to install it through the package manager, meaning you would already be familiar with the system's package manager. Because of this, I think the solution of using a bash function in /etc/profile.d is still fool-proof.

[tjkrobertson]

IMO the cleanest solution is to have a decent CLI frontend for PackageKit so that the user just has to run "pkgkit install" or whatever and it gets handed over to apt/dnf/pacman/etc. PackageKit already exists for this precise reason and it's being wholly ignored for some reason.

[Charadon]

It probably gets ignored becuase packagekit is a bit of a pain. My personal issues with it, is that it's slow and tends to lock the package manager for actual hours at a time. It got to the point, that the first thing I do when I install a new distro, is turn off packagekit's service. And i've heard others have the same issue, like how the other day, one of my friends couldn't install an rpm, and it was because packagekit was doing "something" and we could never figure out what exactly it was doing. So we killed it and just used the system's package manager.

[magnus-ISU]

@Charadon I don't think the problem is so much that you're actually losing much by not working for POSIX shells, especially in this case where the solution is intended to be temporary anyway.

However, I do think that faced with two decisions, one that works for literally any way to invoke a command and adds no complexity to the system, the other that is locked to Bash and Zsh and relies on lines in /etc/profile parsing shell scripts in /etc/profile.d (this is not POSIX, just a thing most distros have via scripting in /etc/profile), I think it makes more sense to do the thing that always works and doesn't lock you in to a specific toolset.

Is there arguments for making at an alias or bash function that I'm missing? Besides, presumably, a user being able to install apt another way, which I'm saying now this should be managed by the package manager and thus the package manager can deal with such conflicts?

@tjkrobertson It is stupid because it doesn't inform a user why that doesn't work or what they should be doing instead, which is a service that a distribution should be providing for its users, at least if it wants to be easy to use.

[Charadon]

@magnus-ISU You should look into opensuse's command not found, it basically solves what your saying with standard command-not-found.

Anyways, as for just having a bash script as apt, on most distros you could do this with a simple update-alternatives. Though, correct me if i'm wrong, arch doesn't have update-alternatives, and thus you would need 2 packages that would need to replace/conflict with each other. So for example:

apt-not-found could be the name of the package, and it can be replaced with the apt or aptitude package. Though, recently I was talking to a opensuse maintainer, and they were talking about how PackageKit (Gnome-softaware, discover) doesn't support conflict resolving... so that's a bit a problem.

So in the end, on some distributions, they'd need two packages for apt, one that contains an echo command telling them what to use, and another that's the actual apt command. And we'd have to acknowledge that packagekit would get confused with this.

[tjkrobertson]

Arch doesn't need to know about what Debian is doing. Debian doesn't need to know that Fedora has changed from Yum to DNF. Fedora doesn't need to understand what the Nix package manager is.

Knowing what package manager your system has is part of the research you should be doing before switching. Seriously, it's one of the only things that's still different between the major distributions. Making this out to be an Apt problem is ignoring the fact that a 5 second Google search would have told you the right thing to do instead.

[tjkrobertson]

@tjkrobertson It is stupid because it doesn't inform a user why that doesn't work or what they should be doing instead, which is a service that a distribution should be providing for its users, at least if it wants to be easy to use.

But it is telling you why it doesn't work. It's telling you that, on this system, there's no binary named apt in $PATH, which just about always means it's not on the system (with the notable exception of Flatpaks, but that's another rant). At that point, it's up to the user to decide how they want to proceed: they can figure out how to use the distribution's included package manager, try and install the package manager they want (which I've never seen go well), or they can change distributions. It is not, however, the job of Arch or any other distribution to know ahead of time what you want to do. That's the user's job, and the user's job alone.

[superterran]

+1 for package-kit, this is the exact problem it's implemented to solve, and if Gnome Software Center is any indication, it does a decent job at that.

[FruityWelsh]

https://jsmith.fedorapeople.org/drafts/SMG/html/Software_Management_Guide/PackageKit_CLI.html

Package-kit does seem to already have a cli interface though it doesn't seem to yet solve the front-end agnosticism to me (i.e. yes you could run any system with pkcon, but guides written to use other package manager will need to be reinterpreted by the user to work). Though with a mature backend this does seem to be a reasonable place to put work into improving to me.

[tjkrobertson]

Seems like things could be improved with a simple awareness campaign, then. I've been using pkcon since you mentioned it and it does the job magnificently.