<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 10 March 2014 16:46, Adam Williamson <span dir="ltr"><<a href="mailto:awilliam@redhat.com" target="_blank">awilliam@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Mon, 2014-03-10 at 11:31 -0700, Toshio Kuratomi wrote:<br>
<br>
> > And I think those subpackages probably _should_ conflict, don't you?<br>
> ><br>
><br>
> Depends. Sgallagh had a desire to mark that a particular system<br>
> implemented multiple products (ie server that also had workstation<br>
> installed). I'm not sure that's a good idea but if we did go that route<br>
> then we'd have to be able to support that with our identifiers.<br>
> Subpackages that conflict wouldn't be flexible enough to handle that.<br>
<br>
</div>Just for the more-public-record, I remain pretty sure this is a bad idea<br>
and don't think we should allow it. You should always be considered to<br>
be running exactly 0 or 1 Products. I think we should consider how to<br>
allow things like 'run a desktop on the Server product', but that<br>
shouldn't be conceived as 'run Workstation on Server'.<br></blockquote><div><br></div><div>As a Smoke Jumper Sysadmin, I agree 100% with Adam. I have spent too many projects/problems/criseses dealing with combinatorics because someone has enabled X with Y with Z with X because they could. If there is one long train of woes, catastrophe, and doom it is where people take limited things and then try to get them to combine. Because you will quickly find ARM+Cloud+Server+Desktop and then realizing that it is completely different from Server+Desktop+Cloud+ARM in how it works. (etc etc).</div>
<div><br></div><div>Either have them run 0 products and get to combine everything they want (eg make their own product), or have them run a product and get a tailored environment known to fix problem ABC. Trying to be more complex than that is not going to solve any problems worth solving in the time we have to solve them.</div>
</div>-- <br><div dir="ltr">Stephen J Smoogen.<br><br></div>
</div></div>