(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.
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
* golang-github-russross-
* go-srpm-macros
* golang-github-cpuguy83-go-
* go-compilers
Build name: "nodejs-6-20180308155546.c2c572ec"
An example of a "nodejs" package [5], build name "nodejs-9.8.0-1.module_1571+
An example of a "nodejs" module [6], build name "nodejs-6-20180308155546.
1. storing two completely different IDs (NVR and NSVC) in the same data structure
[1] https://kojipkgs.
[2] https://koji.fedoraproject.
[3] https://kojipkgs.
[4] https://koji.fedoraproject.
[5] https://koji.fedoraproject.
[6] https://koji.fedoraproject.
On Mon, Mar 19, 2018 at 9:27 AM, Petr Šabata <contyk@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
--
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
