You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.)
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.)
The text was updated successfully, but these errors were encountered: