Keith M Wesolowski writes:
> It would be much better if this were done on a per-file or better yet
> per-package basis, so that distributions could, as they do today,
> elect to include or not include a particular feature. I don't think
> adding a lot of #ifdef SOLARIS is the right answer here - after all,
> do we then allow integration of #ifdef SCHILLIX, #ifdef BELENIX, etc.?
Agreed: this kind of code is a maintenance nightmare.
> If the project team can't isolate their feature well enough that it
> can be easily excluded if desired, and they can't convince other
> contributors that the feature is worth the cost of supporting it as a
> first-class citizen, then the project really doesn't belong in the
> gate.
True. In the case of US-I support, I had initially thought about
delivering it in separate packages: SUNWus1 and SUNWus1u which contain the
necessary inetboot, ufsboot files and Ultra-1 symlinks. I dropped that
plan when it occured to me that this would mean having separate inetboot
and ufsboot files for Ultra-1 and SUNW,Ultra-Enterprise which would allow
booting on US-I systems while the generic sun4u ufsboot/inetboot would
not. Having to deal with those separate files (e.g. for diskless installs
etc.) would be much more trouble than just allowing the generic sun4u
ufsboot/inetboot files to run on US-I again. If this is accepted, it may
be better to include the Ultra-1 etc. symlinks etc. directly in the core
packages instead of separating them into their own packages.
> That's not necessarily the case for US-I support - scoped properly,
> this project could provide worthwhile benefits with little impact on
> other code. But before anyone asks, sun4m (or any other project
True, as the webrev posted before demonstrates. I've the same plan for
le(7D) revival: move it to its own SUNWle and SUNWleh packages, so they
can be included or excluded at will.
> proposing to restore the 32-bit SPARC kernel) would be both impossible
> to isolate and excessively costly for all contributors.
... as has been discussed extensively on opensolaris-discuss in the past.
No argument here :-)
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
