On Mon, Mar 19, 2018 at 08:57:08AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Mar 19, 2018 at 09:27:30AM +0100, Petr Šabata 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).
> Thank you for the detailed reply.
>
> I see the reasons, and the elegance of not placing restrictions on the
> stream field, but I think that's one of those where practicality beats
> purity. _Tooling_ may be improved, but this is also about _humans_.
> With the current format, it is simply impossible to look at a module
> n-s-v-c string and parse it into components. In other words, it's not
> possible to say what the *name* is. This is a major practical issue.
We would really prefer people looking at the structured data
rather than the imperfect string when processing modules.
Modules carry quite a lot of it; strings are just identifiers.
I know it's tempting but doing so might produce suboptimal
results. That said, if people here (or FESCo) feel like decoding
ID strings is crucial, another policy limiting the options in
Fedora might always be added. I'd say it'd be unfortunate, though.
> Frankly, I don't think it's a big restriction to forbid dashes in
> stream name. Colons, semicolons, slashes, spaces, and a host of other
> characters have to be forbidden too. If we establish a convention to
> use plus, underscore, dot, or whatever is the most appropriate, in
> a few months people will not remember why they ever wanted dashes.
Yes, but unlike all of the examples above, dashes are
comparatively more common as word delimeters in this context and
I think is the most natural choice. New rules and conventions
can be defined, of course, but it's still forcing people to
work around ambiguous technological limitations.
P
>
> Zbyszek
>
> > 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.
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
