On Sat, May 17, 2025 at 06:32:47PM +1000, Frank Crawford wrote: > Bjorn, > > On Sat, 2025-05-17 at 09:03 +0200, Björn Persson wrote: > > Adam Williamson wrote: > > > `add-pkg` is not the right > > > thing to use here, I'm not sure where you came across it. > > > > "koji help" describes add-pkg as "Add a package to the listing for > > tag", > > which sounds like exactly what Frank wanted to do. People in this > > mailing list talk a lot about packages being "in" tags. Normally tags > > are attached to things, but once you're used to the idea of tags > > containing packages, it's natural to want to add a package to a tag. > > > > tag-build is described as "Apply a tag to one or more builds", which > > makes sense for the usual concept of tags attached to things, but > > sounds > > weird when you think of tags as containers of packages. > > 100% right. For occasional packagers many of these concepts are > unknown and not easily found. > > I'm not sure where any of these concepts are spelt out, if they are.
I can see how koji's terminology might be confusing here. a package is a entry/name/placeholder in a tag that says 'This package, named ABC can be built in this tag'. You can't normally build arbitrary packages in any tag, they have to be specificially added there first. (but see below). Also packages are the _name_ of a package, not a specific version/build. a build is a particular build of a particular package. a package can have any number of builds. builds must be unique though, they cannot have the exact same version/release. a tag is a collection of packages, with 0 or more builds in them. you can have a tag that has a package added to it, but that package has no builds. tags can also have inheritence. So, for example side tag's in our koji inherit from the main build tag for that release, so all the packages and builds in that tag are inherited into the side tag (thats why you don't need to add pkgs to a side tag, they should already be defined). In this case you can do what was suggested upthread and just build a new version of the package you need and submit it with the rest when you make an update. This is the normal path. There are some tricky things you can also do like tag in a build you need, do your builds and untag it, but you should only do that if you really know what you are doing, because the other build's update might not go stable at the same time as yours and if there's a runtime dependency there, everyone who has that package installed will be broken by the update. I'm happy to help/review any docs changes around this. It definitely can use work... kevin -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
