On 3/15/07, <b class="gmail_sendername">Axel Thimm</b> <<a href="mailto:Axel.Thimm@atrpms.net">Axel.Thimm@atrpms.net</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>this may have been documented somewhere, or perhaps discussed here,<br>but I can't find it: What "repo" is used for the RHEL5 builds? Server,<br>client or the sum or both? If it's the sum are you using *two*
<br>licenses for creating the repo? If it's open for debate I would argue<br>that we should have the sum, e.g. the complete RHEL5 as a base.</blockquote><div><br>This is a really good point. It even breaks down further when you look at client. From the totally useless desktop only entitlement (no emacs is still a sore spot for me) to the nearly complete desktop + workstation + virt. In the situation you've outlined packages would just fail the depsolver on systems without the correct entitlements. Not pretty, but maintaining multiple repos to account for the different Red Hat channels would be a ton of work.
<br><br>What I didn't get a clean picture on is what Red Hat's strategy around client would be. If they plan to be a little more forthcoming with updates on the client release (which they probably should) it means some of the common packages between client and server will fall out of sync. So even while a package in EPEL will build on each system the same package may not run on both because the linked in packages will be different. A client, server split would make since in that situation.
<br><br>We asked about this quite some time ago but Red Hat hasn't given us the final word on this yet. Probably because they still haven't decided how they'll handle the situation yet. Does anyone have a better picture now that RHEL-5 is out the door?
<br><br>Russell<br></div><br></div><br>