On Fri, Mar 02, 2001 at 10:35:06AM -0500, Camm Maguire wrote: > OK, I think I agree. What do you think of having one package which > covers major subarch divisions, or a package providing only the > generic, and allowing the user to rebuild and tune to their hardware? > The latter is certainly simpler, but > 1) It assumes some ability on the users part to handle the versioning > of the custom packages, so that their package isn't automatically > 'upgraded' to the generic > 2) Can't share /usr across different subarchs (does anyone do this > anyway?) > 3) Have to remember to rebuild when upgrading CPU, or moving system > disk into a different machine. > > Maybe these issues aren't really that important, after all. There was > originally some preference expressed on debian-beowulf for this > functionality, but the balance seems to have shifted.
What if you had the package install source and build the libraries in the postinst script, according to a config file that specified what arch/subarch options to use? Then you could configure it once, and upgrades would get it rebuilt when needed. People who wanted to share /usr across subarchs could use symlinks to a per-machine directory that point back to the appropriate shared version. (like /etc/alternatives) It might be hard to automate this, but it shouldn't be too hard to do for the end user. Don't worry about it when packaging. This would make for a self-modifying package, but at least we are generating more files, rather than removing some that came with it. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
