Darren, Jordan, Brock, Thank you for the comments. Please see responses inline.
Darren J Moffat wrote: > Given the above I believe more appropriate names would be: > > opensolaris.driver > posix.group > posix.hardlink > solaris.legacy > posix.link > posix.user > > That then allows for: > > windows.group > windows.user > windows.driver I'm expecting that changing action names at this point would be a hard sell. This is why I suggest using the implicit attribute method instead. > >> pkg.platform (for the operating system) >> values: sunos, linux, windows, darwin > > do you mean Darwin or MacOS X ? darwin. On a Mac, the python platform.system() method returns darwin. Who knows, maybe we'll get pkg(5) working on the iPhone too. > >> pkg.ISA (for the instruction set architecture) >> values: i386, sparc > > shouldn't ppc be included in here as well for the Darwin/MacOS case ? pkg.ISA isn't really needed for darwin executables. Since Mach binaries include multiple ISAs, we are delivering universal binaries for darwin. Jordan Brown wrote: > Please ensure that for a directory that already exists, the settings > will remain unchanged (and not revert to the OS default). I suppose > that the same might apply for a file, but having two packages deliver > one file is less common (and may not even be legal in IPS, I don't know). > > yes. Jordan Brown wrote: > There are also compatibility aspects: if a new action is added in v1.1 > of the standard, can a package that uses the new action be processed by > a v1.0 implementation? > Action implementations will need to evolve in a compatible way. > Brock Pytlik wrote: > >> Tom Mueller (pkg-discuss) wrote: >> >>> [snip] >>> >>> c. The actions.fromstr method will be modified to pass through >>> unrecogized actions rather than throwing an exception. This is to permit >>> cross-platform packaging publishing, e.g., so that a Windows-specific >>> package containing a Windows-specific action could be published to a >>> depot server running on Solaris. Also, this causes unsupported actions >>> to be ignored by the client. >>> >>> [snip] >>> >> This part bothers me, and I'm not sure I understand why it's necessary. >> Being able to parse a particular action (I don't believe) does not imply >> that the action can be executed on the parsing platform. Basically, I >> don't see a reason not to ensure that action formats are understood >> (parsed) by all depot platforms. I'd be troubled that responses from the >> server (search for example) would be dependent on the underlying >> operating system of the server. I could be wrong, but this seems like >> something we could solve. >> This is a good point. I don't think we considered the impact on search when we discussed this earlier. The implicit attribute specifications and appropriate filters would work just as well for the multi-operating system case as it does for the multi-ISA or multi-image type case. So that can certainly be a fall-back solution. Tom _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
