Package/program name conflict

[hwti]

On at least Fedora and Archlinux, there are already packages with the same name and executable name.

https://packages.fedoraproject.org/pkgs/q/q/
https://aur.archlinux.org/packages/q

This means that if I install q_0.8.2_linux_amd64.rpm on Fedora, dnf see the distribution q package as an update.

[natesales]

The name q may change in the future, but for now you can copy the binary over. It's statically linked and doesn't depend on any config files or anything aside from the binary itself.

[seththeriault]

This also conflicts with an existing Homebrew package:

https://formulae.brew.sh/formula/q

[natesales]

The homebrew package can be installed with brew install natesales/repo/q after adding the natesales tap with brew tap natesales/repo https://github.com/natesales/repo.

[holgersson32644]

First of all, thanks for that nifty CLI tool ;)

FTR: In Gentoo/Linux we have a similiar problem, as the name "q" is already taken by a package related to package management.
In my overlay (some kind of an unofficial repository) I packaged q as net-misc/q but renamed the binary into q-dns there.

Are you interested in some "public brainstorming" to find a short but distinct name for q?
I propose one of the following

• q-dns (or qdns)
• q-ns (or qns)
• magical-creature-from-startrek ;)

WDYT?

// Edit 2022-09-27 / 07:15 UTC: Funnily I just re-read the README seeing the AUR package also uses q-dns as its name.

[Seirdy]

I strongly recommend changing the binary name to something unique, as a name conflict will prevent creating distribution packages. qdns is taken by another smaller DNS-related project, unfortunately; however, q-dns seems safe. I prefer qdig as it's less ambiguous and easier to remember (it's like dig, but with DoQ!)

There's also obdig (dig with OBlivious DNS over HTTPS), which highlights its unique ODOH capabilities.

Checking Repology, the AUR, GitHub, and Fedora package+binary name conflicts: qdig and obdig seem fine.

[classabbyamp]

any updates on this? I'm working on packaging this for void linux, and we generally keep with the upstream naming, but if the name is going to change I'd prefer not needing to change the package's name

[rahilarious]

This is a really handy tool.

Besides problems in packaging, project @natesales is hurting itself by not naming it in search-friendly name. Because of this single letter name, there is no branding as well. How would somebody quickly tell your friend about this utility? "hey, checkout this q?" One has to either send link or remember your name and tell "checkout natesales/q" which is highly unlikely to happen.

Author is not living upto his last name "Sales" cause this is not great salesmanship :-)

[polarathene]

q-dns or qig both seem fine 👍 (qdig / q-dig are a bit easier to pronounce though and more familiar dig association to DNS CLI tools)

Agree that it's not the easiest name to discover, I just search "q dns github" if I'm lazy 😅

Since doggo is a competing option, if you want to stick with the idea of similar names to others (qdns) you could go with doqqo? (1 less letter, efficient! 😂 ). Both dig/doggo based variations technically blend in with all the others in the README comparison table. goq is used elsewhere, but doqqo is fairly unique if you don't mind the overlap with doggo in search results (probably a bonus, besides some potential user confusion).

I'm not familiar with packaging, would it be much of an issue if another package installs a binary of the same name too? Or is this only about the package name? Users could always alias a longer name to q if they like 🤷‍♂️