Hi, On Mon, Jan 24, 2005 at 01:40:03PM +0100, Robert Millan wrote: > On Mon, Jan 24, 2005 at 10:11:26AM +0100, Guillem Jover wrote: > > I've been thinking on implementing this for a long time. As > > Robert has presented an implementation to the Architecture > > handling problem that does not convince me at all, so instead > > of just sitting here and criticize his design I've coded mine. > > You say that you my work doesn't convince you, but yet you refuse > to criticize it. This dessign is not a quick-and-dirty hack, but > the result of a proposal I started in Nov 2001 (to whose dessign > nobody objected ever since).
Yeah I meant to criticize it, but then forgot. :> Also I was not aware of that proposal. Or I cannot recall you telling me every time I brought out the alias idea. :> > I brought this here into discussion precisely to get feedback > about it, so if you have concerns with my patch please explain > them. Ok, I see a couple of big problems with your implementation. * Currently a real Debian architecture is composed of kernel/system + cpu and that's a pair of characteristics that cannot and will not be decoupled easily from each binary package, the archive structure or the tools that handle them. So splitting that info in the source package definition just makes things more complicated w/o a reason. That information will be merged back anyway when creating the binary package. Your current syntax does not make possible to specify that a binary package is available just for hurd-i386, linux-i386 and linux-alpha, for example. That can be done with the current syntax, I think this is a step back. With mine it can be specified just fine. * The Build-Depends syntax is not well defined as Goswin has pointed out, and it have the same problem as the above point, trying to decouple an information that it's naturally joined. For example you specify your disire to have something like this: [cpu: i386 ...] [system: linux ...] I assume the "..." specify additional entries, so in that case what valid permutations would you choose, and then how would you specify convintations that don't include all permutations? So I see the splitting approach just over complicates things instead of making them easier to deal with, I think that extending the current syntax with some new aliases is the saner solution, also the concept is not as disrruptive in developer minds as the split one. :> regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]