On Mon, Mar 19, 2018, 10:20 Petr Šabata <con...@redhat.com> wrote:
> 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
>
So you think having to send a request to a web service instead of just
parsing a string locally with one line of code is a good trade-off for
allowing dashes?
Gaining one additional allowed character and therefore losing the ability
to parse this locally just seems mad to me ... compared to that,
introducing a "convention" of using underscores (or sth. else) as word
delimiters within fields looks more reasonable by multiple orders of
magnitude ...
Just my 2c.
Fabio
> 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@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
