(a repost from the infra list)
Please note that modules (and therefore module builds) may reference to multiple RPM builds. Also, the module name doesn't need to match any RPM name. Therefore getting package names from the module build name would not be possible anyway. As an exapmple, see the following build: https://koji.fedoraproject. org/koji/buildinfo?buildID=1057280 Build name: "golang-ecosystem-2017.0-20180312141905.40a0ab3e" If you open the modulemd [1] (a module definition file) linked at the bottom of the page, you'll see that this module build contains four RPM components (SRPMs): * golang-github-russross-blackfriday * go-srpm-macros * golang-github-cpuguy83-go-md2man * go-compilers The page also says "Package Name golang-ecosystem" which links to a "golang-ecosystem" package [2] in Koji. That's weird, there is no such package named "golang-ecosystem". The page lists two module builds, not two package builds. Another example, where a module references only one RPM package and the module name matches the package name: https://koji.fedoraproject. org/koji/buildinfo?buildID=1055922 Build name: "nodejs-6-20180308155546.c2c572ec" Here, the modulemd [3] lists just one RPM component (SRPM): * nodejs The page also says "Package Name nodejs" which again links to a "nodejs" package [4] in Koji. But this time, there *is* a "nodejs" package as well as a "nodejs" module. That page lists both! An example of a "nodejs" package [5], build name "nodejs-9.8.0-1.module_1571+4f4bc63d" which is a good old NVR. An example of a "nodejs" module [6], build name "nodejs-6-20180308155546.c2c572ec" whic is not an NVR, it's a NSVC (name, stream, version, context). So after going through these two examples, I think this discussion should be more about: 1. storing two completely different IDs (NVR and NSVC) in the same data structure 2. listing two different build types (package and module) in the same place, both as package builds [1] https://kojipkgs.fedoraproject.org//packages/golang-ecosystem/2017.0/ 20180312141905.40a0ab3e/files/module/modulemd.txt [2] https://koji.fedoraproject.org/koji/packageinfo?packageID=25886 [3] https://kojipkgs.fedoraproject.org//packages/nodejs/6/20180308155546. c2c572ec/files/module/modulemd.txt [4] https://koji.fedoraproject.org/koji/packageinfo?packageID=15154 [5] https://koji.fedoraproject.org/koji/buildinfo?buildID=1055873 [6] https://koji.fedoraproject.org/koji/buildinfo?buildID=1055927 On Mon, Mar 19, 2018 at 9:27 AM, Petr Šabata <con...@redhat.com> wrote: > On Sun, Mar 18, 2018 at 07:09:23PM +0000, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Mar 16, 2018 at 04:14:27PM -0400, Randy Barlow wrote: > > > On 03/16/2018 04:04 PM, Dennis Gregorovic wrote: > > > > modules are not RPMs. I would not expect them to necessarily use the > > > > same format as RPMs. If we take koji out of the equation, we have > > > > module builds in N:S:V:C format and module RPMs in N-V-R.A format. > They > > > > use different separators, but both can be parsed consistently. > > > > > > I don't contest the above, but I am arguing that it is needlessly > > > different and causes infrastructure software to need to handle module > > > strings differently than they handle RPMs and containers. Perhaps there > > > is a benefit that I've not been made aware of yet, but from where I sit > > > it seems like a change that causes problems without bringing a tangible > > > benefit. > > > > > > The reasoning I've heard so far is that this allows stream names to > have > > > -'s in them - is that important? I don't know it to be, but am open to > > > be convinced. Thus my question - is it important enough to have -'s in > > > stream names to justify the work needed to make all things that > interact > > > with Koji parse them using a web service rather than local code (such > as > > > rsplit('-', 2) in Python)? > > > > So, is anyone knowledgeable who can answer this question? > > > > If nobody can, then mostly likely the answer is "no, it's not important". > > The reason for allowing hyphens was to, maybe ironically, allow > more flexibility and to avoid unnecessary restriction on names. > > While streams are often presented as upstream versions in > most of the examples, they're strings and are, in reality, an > extension to the name. Your stream might be just "6" or "8" but > it could also be "experimental-build" or "performance-patches". > Current tooling shortcomings shouldn't influence how details > like this are designed. The tooling can be fixed (or enhanced, > if you prefer). > > The ordering of the fields is based on the importance of > the field to the user and most of them are optional when > people interact with modules using their package manager. > "module", "module:stream", "module:stream:version" are all > valid inputs (we do not expect people to use context directly; > it's just serialized that distinguishes individual builds for > stream expansion). Context is indeed similar to dist-tag, > just richer. Given the parallel availability, your modules > aren't built just for a release of Fedora, they are built for > any valid combination of their modular dependncies, with the > Fedora release being just one of them. > > Note, as Patrick's already said, these names do not leak > anywhere. Modules are not RPMs and are not handled as such. > This, AFAIK, only affects what you see in some parts of the > build and update system (and on the bus). > > Also note that generally if you have access to modules, you > have access to their (structured) metadata. > > P > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > -- Adam Šamalík --------------------------- Software Engineer Red Hat
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
