On Tue, Aug 08, 2017 at 03:11:38PM -0400, Matthew Miller wrote:
> On Tue, Aug 08, 2017 at 09:04:40PM +0200, Petr Šabata wrote:
> >   dependencies:
> >     buildrequires: &deps
> >       platform: [f28, f27, f26]
> >       shared-userspace: [fancy, nonfancy]
> >     requires: *deps
> > 
> > Another point that came up later -- instead of shared-userspace,
> > imagine different streams of your favorite dynamic language.
> > That might make it the reasons for this more obvious.
> So, like:
>   dependencies:                                                               
>     buildrequires: &deps                                                      
>       platform: [f28, f27, f26]                                               
>       python: [2.7, 3.6]                                                      
>     requires: *deps    
> Hmmm, though. This doesn't really make sense if the module in question
> just happens to use python. In that case, why build it for different
> dependencies? Just pick one; the user won't care.

If you pick one, you make your module unavailable to people
who chose to install the incompatible other on their system.
Building it (automatically!)  multiple times allows the user to
choose, rather then the developer forcing their choice onto them.

> If on the other hand, the user *does* care (perhaps the module is a
> framework where more stuff is then written in the underlying language,
> so the user wants to choose). In that case, wouldn't we *want* that
> surfaced into the stream name?

No.  This allows us to ship the same build in multple
variants and no matter what platform and python (following the
abovementioned example) the user has installed, the right binary
variant of your module will be deployed.

If they decide to switch to another platform or python, your
application will be switched for the variant which is compatible
with those.  The variants will be distinguished by the context
flag, mostly in the background.


Attachment: signature.asc
Description: PGP signature

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to