From: Richard S. H. <he...@un...> - 2004-05-12 17:59:15
|
Stephane Frenot wrote: >Yes, I already have such problems on my inner applications. >All bundle managing scheme (rpm, deb, ebuilds) map version to archive >names... obr should also do that. I think the earlier the better... > > There are many issues here: 1. OBR is just intended to be simple. 2. OBR meta-data is exactly the bundle meta-data (modulo some additions). 3. Something that solved every problem would be great, but I don't have the time to do it. Related to this, while working out at the gym, I began to start to think about the fact that OBR meta-data is simply bundle meta-data, thus this means that we must probably allow spaces in bundle name. OBR "bundle name" is just the manifest "Bundle-Name", which is intended to be a human readable string. And more to the point, we have to realize that what we are debating is the command-line syntax to the bundle repository service. If you use the new OBR panel for the GUI shell, then these issues sort of go away, because the user just clicks on the one they want. Thus, if there are (eventually) multiple versions, they can easily select the one they want with the GUI and afterwards Bundle-UpdateLocation is automatically used to update that installed branch. The [proposed] meta-data for the new OBR probably covers most of the scenarios and it doesn't seem like command-line syntax should dictate design. So, while syntax like... obr install "Service Binder";1.2.0 or for non-space bundles: obr install log;1.1.0 ...may seem a little verbose, is it really a problem? -> richard p.s. Most people do not really realize the fine level of decision making that goes into project management, huh? :-) |