On Thu, Dec 10, 2009 at 11:10 AM, James Lee <[email protected]> wrote: > > There is the possibility that a later classutils won't be compatible with > older installed packages when they eventually require update and so I > object to the principle of requiring global installation and a common > version.
Well, if we were talking about [random anonymous 3rd party vendor], I can see how this is a concern. but seeing as how WE are the vendor... I think we can put this concern to bed fairly easily ;-) A quick off-the-cuff solution: We declare that classutils implementations must be backwards compatible. If you want to do something incompatible,you must do it in a newly named class. Problem solved? > If I had the solution I'd have made a suggestion long ago. I'm saying > although I haven't complained myself I do support anyone else for whom > it is an issue and I support the quest for an alternative. ah. fair enough there. i wouldnt ever say "this is perfect, i'm going to ignore any other proposals for alternatives". I would say that I just want other alternatives to be *at least as good*. > It might be possible to use the existing build/sed classes and provide > developer tools that write the necessary code to work with those classes. > I make ghostscript, groff and some others to install the correct paper > size using request and the existing build class. I've no idea if the > standard classes would work or if another technology is needed but as > long as CSW needs to write to /usr there is room for improvement. Well, there are probably some things for which we can use existing sun provided classes. But they ARE *very* limited. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
