Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux