(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 <contyk(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Adam Šamalík
---------------------------
Software Engineer
Red Hat