Dave Miner wrote: > Channing Lovely wrote: >> As I said before, I am fine with your code changes. I am pretty sure >> that introducing some weird checking into the DC code is probably not >> the way to go. However, we need to do something. The DC page on >> opensolaris.org says >> >> In order to use the Distribution Constructor, you must have installed >> Solaris Nevada build 71 or a later build on your system. >> >> and that is clearly not true anymore. The SXDE 1/08 won't work (based >> on 79b) for several reasons, and preview 2 will probably fail due to >> the SUNWclofi issue. I think the main page on opensolaris.org needs >> to be updated, and there should be a bug against the man page for >> lofiadm. > > You have the rights to modify the opensolaris page, so use them if you > see something that isn't right. > > I suggest these choices: > > - Eliminate the validation of this parameter, let it fail if it's > wrong when that point in the build is reached Without checkpoints this could be painful for the user. But probably the least frustrating for the user. Once checkpoints go in, it's not a big deal to have the build fail here. > - Only issue a warning if Jean's proposed validation fails With the number of messages we spew to the screen in the IPS retrieval and the gnome stuff I hesitate to do this. I'm afraid it will get lost in the cruft. If we can get rid of some of those messages, this might be nice. But it would be confusing to see this warning and then later everything works fine. > > - Require that the build system have a version of lofiadm which > supports the compression we want (potentially at a configurable path); > in which case, we'd use that one to build and not the one we install > in the proto area. > My concern here is whether or not people can upgrade their SUNWclofi package. So then we need to supply a configurable path which just seems like yet another parameter for the user to think about. Doesn't seem important enough for that.
So I don't like any of my choices. But I think I dislike 1 the least. Clay agreed and I didn't even lead him down that path. He actually liked combining 1 and 2. > Jean, your testing is suspect here: lines 113 and 114 in > build_dist.lib don't agree on what path is being used. Actually there are 2 bugs here that made things appear to work when I tested them. As you noted, I have conflicting paths. Unfortunately, my testing didn't find this because neither one is defined and thus defaults to /temp. I've figured out why. Jean
