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. P
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
