Re: Sarge-built binaries running on Woody systems?
On Thu, Dec 29, 2005 at 01:45:55PM -0600, Matt England wrote:
> Sarge-built binaries running on Woody systems:
>
> Is this feasible?
>
> I'm not talking about package management...just the raw, binary.
>
Backward compatibility is not guaranteed. That's why, for example,
some packages are back-ported voluntarily. Openoffice.org version 2
is wanted by Sarge users whereas it's only currently in testing (to be
Etch when released) and unstable. Someone will probably back-port
it given time - but it's quite large.
> Are dynamic-library-management tricks needed? Does the Debian testing
> authority (or whoever is given responsibility of anointing Debian releases
> for distribution) make any attempt at backwards compatibility for this kind
> of stuff?
>
At this point we support security fixes for "old stable" as far
as I know, but new packages wouldn't go into Woody. Build for testing /
unstable if you want to go into the next release.
New packages wouldn't go into Sarge at this point: if your package
is jolly nice to have, build a version separately targeted at Sarge
users.
> As per similar motivation for my previous redhat-on-Debian binary porting
> conversation: I'm hoping that one Debian build will work on many Debian
> systems.
Given that Debian releases once every 18 months or so (with point
releases in between) but freezes prior to release- you're talking the
difference between RH 7.3 and 9 or 9 and RHEL 3, or virtually the entire
history of Fedora,or Suse 9.0 - 10. Glibc changes happen, as do compiler
changes. I'm not sure even that a pure Debian build will work on Knoppix /
Kanotix and possibly won't on any Ubuntu.
>
> Can I at least count on a Woody-built binary working ok on a Sarge-based
> system? In this context, how far "back" can I go to get "forward"
> compatibility? (ie, how many revs before Sarge can I go back to "build on"
> and still get Sarge compatibility?)
None guaranteed. But at this stage in the game, there are likely to be
fewer and fewer Woody users.
>
> If there are reasons why the answer is "depends" instead of a flat "yes" or
> "no": I would love to know these reasons. This is what I'm specifically
> hunting for.
>
> -Matt
>
HTH,
Andy
Reply to: