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.
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.
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
