package name mapping

[icy]

Example

$ pacapt -S httpd

will be translated to apache2 apache or http according to the OS where pacapt is running.

The first goal is to support some popular packages

[ssbarnea]

👍

[darnir]

Any updates on this? I would like to try and help if possible. This feature would be very useful in my usecase for pacapt

[NgoHuy]

we have a big table to map these packages, you have any idea to query it fast and correctly ? :)

[icy]

@darnir Sorry for any inconvenience. I know it's very useful (also for my daily boring jobs) but the only idea I have is to create a big table of all packages, e.g,

#arch #debian #centos
httpd apache2 httpd2
...

and then pacapt script will look up in this table for every run. I don't think this is good way, as it will slows down the script when the table is big. Another problem is that we need a simple way to manipulate the table of packages.

But... let me give it a try with a simple implementation. Stay tuned!

[pabru]

@icy Just a couple of things I was thinking of:

1. What if on some distros httpd is equivalent to more than one package? There would need to be a way to specify multiple packages per mapping in this case.
2. What about the distros which split off -dev, -doc and so on, like Debian and Ubuntu? Since Arch includes everything and the kitchen sink in its packages by default (which I personally don't mind too much), does this mean that those extra packages should be included in these distros as well?

[icy]

@pabru It's kind of fuzzy searching which is not very useful as far as I see in my daily life; what I really want is exact match. For example, when I write some Dockerfile for multiple distributions, I only need to write pacapt -S apache, and that's all: correct package will be installed.

(2) I think we need to respect distribution's behavior insead of creating similar behavior between distributions.

Please note I haven't started working on this. There is a problem that [now] pacapt's job is to translate the options and it doesn't try to learn user' input. For example, when you enter pacman -Ss [some options] foo, you intend to find foo; however [now] the script doesn't know that. To provide more knowlege to the script, some more advanced arguments parsing is required, and I don't see any trivial way to do that.

[michael-dev2rights]

@icy @pabru
One suggestion which will allow packages to be referenced (from https://unix.stackexchange.com/questions/275212/package-name-translation-across-different-distros) is to allow packages to be referenced by what file they will install. Another suggestion would be to allow them to be referenced by what commands they will add to the environment (which extra executable files appear in the $PATH).

The data needed for both of these suggestions could be automatically generated. Initially the commands in the path could be generated simply by looking at /bin ; /usr/bin and /usr/local/bin. Next, when someone finds a package that they need that doesn't fit, by looking at the actual default path on the given system and then finally, if this ends up really important, by comparing all available commands in the path before and after installing the package.

[Mithrandir2k18]

An idea that came up that could work is have something like .pacaptrc or pacapt -S httpd --packagemapping mypackagemapping.json/yaml/.... Basically a file with custom mappings for some of the distros, e.g. if my install script targets only arch and ubuntu, I'll have one entry for the name I want to map, e.g. httpd and a lookup into the provided file would find it and map it to apache or apache2 respectively. If it's not in the file it'll simply try to find and install httpd.

This way one could easily deploy the script alongside the mappings-file and maybe even share it here via pull request to build a large mappings file that slowly gets more complete over time.

[icy]

@Mithrandir2k18 Thanks for your idea.

Generally pacapt doesn't look into details of the user input. They don't really care if there is package name specified from the arguments. that's still possible to have a support for package mapping, by giving a simple (pre)hook. Let me wrap up some code for this to see how it works. Weekend is there... stay tuned. Thx