butido release rm only respects version number but not release_number (second, third build of the same upstream version)

[christophprokop]

$ butido release rm --from opensoftware tree "1.8.0-2"
Error: release command failed

Caused by:
    NotFound
prokop@dunwich packages $ butido release rm --from opensoftware tree "1.8.0-1"
Error: release command failed

Caused by:
    NotFound
$ butido release rm --from opensoftware tree 1.8.0
Going to delete: /scr/dunwich/prokop/butido/releases/opensoftware/opensoftware_tree_1.8.0-1.8.0-2.el7.x86_64.rpm
Going to remove from database: Release with ID 117 from 2023-01-18 23:50:51.018218
Continue? yes
prokop@dunwich packages $ butido release rm --from opensoftware tree 1.8.0
Going to delete: /scr/dunwich/prokop/butido/releases/opensoftware/opensoftware_tree_1.8.0-1.8.0-1.el7.x86_64.rpm
Going to remove from database: Release with ID 114 from 2023-01-18 15:16:34.816460
Continue? yes
$ butido release rm --from opensoftware tree 1.8.0
Error: release command failed

Caused by:
    NotFound

[primeos-work]

Unfortunately we're running into some design limitations here: Butido isn't aware of any release versions/numbers - in the DB/Rust model, a Package consists of an id (i32), a name (String), and a version (String). The package name and version correspond to the name and version keys of the TOML files. We later (I suppose) added support for release numbers/versions but that "hack" bypasses butido by using an environment variable (environment.PACKAGE_RELEASE TOML key) - this can be used for the file name but it doesn't end up in the package version stored in the DB.

Have we ever tried adding the release number to version instead of using environment.PACKAGE_RELEASE? I guess that should be possible. The main problem would probably be the dependency resolution but it should be possible to simply ignore ("-[0-9]+") suffixes (might not be a good idea though as the upstream version could use that pattern too).

Anyway, I'd say we have two options:

1. Add an additional package attribute (release might be a good name for the DB and TOML key) to make butido aware of release versions. (A clean solution that might also help in other places but a bit of a "major" change.)
2. Add a CLI option to filter by the release artifact path (e.g., /scr/dunwich/prokop/butido/releases/opensoftware/opensoftware_tree_1.8.0-1.8.0-1.el7.x86_64.rpm (from the example above)) as that is already stored in the DB. It would probably be useful to support regular expressions so that one could also filter by distribution and architecture. (This is basically another hack and could easily result in false positives like when matching for 1.8.0-1.)

[christophprokop]

at the moment the release mechanism does not match our workflow anyway