Hi, I'm not sure if that's something guix needs to be aware of. If the name differs very much and guix naming conventions differ plus it can not be found through any of the fields, it makes sense. But you probably don't want to track the different conventions used by various package managers as it is not really low-effort without knowing written and unwritten conventions and where to find them.
just my initial thoughts on this, knowing a fair share of PMs. Josh Marshall transcribed 2.5K bytes: > I'm starting to collect software that needs packaging, and one thing I'm > running into is that naming conventions between the source project, various > distros, and guix itself have some drift. Something which seems low effort > but would ease translating between various nomenclatures would be to track > package aliases. These would be non-canonical in guix, but like shells > sometimes making suggestions as to what program you might have intended to > type would make life easier. > > The approach which I think makes the most sense is to add an optional but > encouraged field in package definitions which takes a list of alternative > package names. When using `guix search` this field could also be > evaluated, and when `guix package -i` is invoked and the target does not > exist, these aliases could be searched through for similar names to the > non-existing target and suggest the actual package they might have intended. > > This appears that it could be low effort, not interfere with any commands, > not really change the interface, and make life easier. Anybody have any > thoughts as to whether this would be a good idea or not?
