On Sat, Dec 31, 2005 at 08:01:37PM -0600, Matt England wrote: > I'm still looking for any guidance on this topic. > > In summary: > > Can one run Sarge-built binaries on Woody?
In general, no. It will depend on the binary: it will depend on how it was linked. It may depend on how it was compiled and with what C/C++ compiler. This is _NOT_ a good idea. If you are back-porting, you use a system running that code vintage. [Could you run a binary for RH9 on RH 7.1? Clue - you can't necessarily because of library and rpm format changes at about RH8. Could you run a binary for RH 7.1 on RH 6.2? Clue - you can't because of lots of incompatible changes from RH6.2 - 7.0. Similarly for most other Linux distributions and, possibly, between Solaris versions. HP Tru64 is picky about versions and HP-UX is picky about minor revisions ...] This is a very similar question to saying "Can I run <cool binary for Ubuntu/Mepis/Kanotix> on a vanilla Debian Sarge system?" It depends - but the answer may well be no. > Can one run Woody-built binaries on Sarge? > Possibly. It will depend on the binary and on how it was linked. Compiler is potentially less of an issue because later compilers are more capable than their earlier brethren. It is probably worth a rebuild anyway because later compilers are also more standards compliant and "picky" about poorly written code - code that was acceptable under GCC 2.95 with all warnings turned on may fail under GCC 4.0 :) 3.0 - 3.1 should be less of a problem than 2.x -> 3. > In the same context, how well would Debian 2.x-built binaries work on 3.x > and vice versa? > To be honest, I go back as far as Debian 1.1 and have been a developer since about 1.3. For building small memory size, special purpose systems anything prior to 3.x is worth looking at - if only to marvel at exactly what will run on a 386SX clocked at 16MHz with 4MB of memory on 80MB of disk :) For most people they will seem inadequate when compared with current Linux so, in reality, unless you are working on an embedded microcontroller or something similarly constrained or have significant investment in (proprietary tools | cross compilers | specialist applications tied to kernel version), consider systems running Debian 2.x as candidates to upgrade or replace where practicable. For Debian, two or three years of concerted effort goes into each major release and several months of bugfixes and security patches into each point release: anything running significantly old versions is a long way back [to the extent that I'd have to dig out disks and rebuild a box running Potato to remember what it had and what the problems were] so anything running 2.x is ripe for replacement even in terms of hardware age. Old versions seem more golden in retrospect - but a couple of days of running them make you appreciate what you have ** > For what it's worth, I soon have to establish some Debian > binary-to-test-system rev-control policies before I got into first round > test on my group's software. > If your group has full scale test policies: follow them _first_. Seek to build Debian packages that are Debian policy compliant on a Sarge system and they should drop in to a Sarge system. It may be worth asking serious questions on packaging on another list e.g. debian-mentors. CHECK FOR NAME SPACE COLLISIONS Build a multiboot machine with three or four large disk partitions or build a machine with three or four virtual machines inside and install Debian stable/testing/unstable on each disk partition/virtual machine. [Instances of qemu / Xen might do - VMWare, although commercial, otherwise] Do your builds on there. You may need to maintain one code base but build for multiple distributions: IMHO, you should still build the code for each distribution at that distributions code maturity level. If building for 3.1 build on 3.1, if building for Etch (current debian testing) build using testing and so on. Unless you are working under an NDA, some idea of the magnitude of the problem may also help - are we talking one binary and a couple of small libraries or something large and intertwined like Apache/Postgres/MySQL size? C/C++ or some other language? Filesystem placement (is this something for /opt)? Licence? Andy ** I've had enough - I'm going back to 1's and 0's. You lucky *&#!*, in _my day_ we only had 0's and could only dream of the day we would be given 1's :) > -Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
