New control field proposal which could help on gcc3.2 transition

[Manuel Estrada Sainz <ranty@debian.org>]

 Hello all,

 I wrote the following proposal a while back, but decided that since it
 was post-woody, I would wait. But woody is out and I think that it
 could also be usefull for the gcc3.2 transition.

 Please comment

 Thanks for your time

 	ranty

-- 
--- Manuel Estrada Sainz <ranty@debian.org>
                         <ranty@bigfoot.com>
			 <ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.

Debian packages have been repeatedly bitten by the fact that a package
breaks its ABI as it evolves, which means that dependencies like:
'foo (>= X.X-X)' ends up not been quite enough; Something like 'foo (>= X.X-X),
foo (<< Y.Y-Y)' would be more efective, but Y.Y-Y is usualy unknown when
writing those dependencies.

There are currently a couple of solutions to this:

  1) Change the name of the package
     * I don't think this is elegant
     * e.g.,
         * libsdl1.2debian
         * libc5->libc6 transition (appending the infamous 'g')
     
  2) Depending on a fixed version of the package 'foo (== X.X-X)'
     * Well, this is quite unflexible and is only usefull with experimental
       libraries and the like.
     * Requieres previous knowledge of the problem.
     * e.g.,
         * libgtk1.3 packages.
	 * libsdl1.1 packages.
	 * galeon/mozilla

  3) Keep a Compatible version and make new version with a different name
     * May be unpractical.
     * e.g.,
         * liborbit0/liborbit2

  4) Conflicting with all packages which have problems with the new version
     * This is ugly and error prone.
     * e.g.,
         * some python changes a while back.


An idea has been floating in my mind for a while now, how about adding an
'StableABISince: Y.Y-Y' field to the control file of 'foo' so that:

 a) any versioned dependency on 'foo (>= X.X-X)' will be considered broken if
   'X.X-X < Y.Y-Y'
 b) any unversioned dependency on 'foo' will be considered broken if foo has
    an 'StableABISince' field.

An example of how the libsdl1.2debian name could have been prevented with this:

	Before breakage:
		libsdl1.2/control:
			Version: 1.2.2-3
	
		vlc-sdl/control:
			Version: 0.2.90-1
			Depends: libsdl1.2
	
	After breakage: vlc-sdl will be considered broken.
		libsdl1.2/control:
			Version: 1.2.2-3.1
			StableABISince: 1.2.2-3.1
	
	After fixing vlc-sdl:
		vlc-sdl/control:
			Version: 0.2.90-2
			Depends: libsdl1.2 (>= 1.2.2-3.1)
	
	Future libsdl1.2 release: vlc-sdl's dependency will be ok.
		libsdl1.2/control:
			Version: 1.2.2-3.3
			StableABISince: 1.2.2-3.1
	
	Next breakage: vlc-sdl will be considered broken again
		libsdl1.2/control:
			Version: 1.2.2-8
			StableABISince: 1.2.2-8
	
	After fixing vlc-sdl:
		vlc-sdl/control:
			Version: 0.2.90-7
			Depends: libsdl1.2 (>= 1.2.2-8)

And so on.

And now that we are talking about gcc3.2 transition, this could also help on
that. It would allow the same effect as appending the 'c' but without
appending it.