Peter Tribble <[email protected]> wrote: > First, you need to stop saying "must" and attempting to > dictate design and implementation decisions.
Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. > > > Well.... > > > > - IPS must not be the only packaging > > > > It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, > and/or no packaging at all. Well, where is the SVr4 package meta data in Illumos? Note that IPS meta data is limited compared to Svr4 package meta data and for this reason, there is no way to convert meta data correctly. > > - /sbin/sh may be a link to the Bourne Shell > > > > Why is this relevant to collaboration? Because for being able to collaborate, we need to have a common understanding of what is preventing collaboration. This results in avoiding changes that prevent collaboration. > This is a good example of where collaboration matters. If this is > important to you, and you want the system to behave correctly > with an alternate /sbin/sh, then log bugs against illumos, > preferably with fixes. However, as with all projects, if having > it fixed matters to you, you have to do the work. Illumos would need to verify first that Illumos is collaborative. Currently we have the unfortunate state that Illumos did not include some software even though this was promised and a code review has been presented. Colaboration of course also means that partners are trustworthy and implement promises. Once Illumos turned into a trustworthy and collaborative entity, it makes of curse sense to file bugs against Illumos. > - scripts need to be open for being able to mount /usr using > > the Bourne Shell. > > > > We're off into the realms of distro-specific implementation artefacts. > This sort of statement doesn't even make sense for some distros, > and the concept it refers to isn't part of illumos at all. I am sure whether you understand what collaboration is... if we like to share important scripts, we need to have a common understanding of what others are interested in. Specific changes at one side may prevent collaboration at certain points and this is such a point. Being able to have native (SVr4 package based) zones on all distros would be another thing to look at. In any case, collaboration means that one distro does not dictate constraints that affect other distros. > > > - We need to find a way for versioned libraries to support > > as much binary compatibility as possible. > > > > That's how shared libraries, versions, mapfiles, and filters > work. But again, this is largely irrelevant - binary compatibility > has often been out of fashion in many open source projects, so > it's not a problem we can solve. And it's a much smaller part of > the overall compatibility question - what versions of interpreters > are present, what build options were chosen, where are applications > installed? If we like to collaborate, we need to decide whether there should be binary compatibility. I remember that in the late 1990s, Linux was so fragmented, that it was impossible to run a binary on distro a if it was compiled for distro b. OpenSolaris has a much smaller community and I am not sure whether OpenSolaris will survive too much fragmentation. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
