Policy proposal for compatibility packages

[Les Mikesell]

Kevin Kofler wrote:

>> Free vs. non-free has nothing to do with the issue.  It has to do with 
>> how long you want existing binaries to continue to work, and how long 
>> you want to enable/encourage people to continue to compile in a way that 
>> does not use the current API.  There is never a reason to break existing 
>> binaries unless you hate your users or there is no other way to move 
>> forward.  But you may want to make it obvious that things should not 
>> continue to be compiled against the deprecated API.
> 
> You are still missing my point!

And you are missing mine.  It doesn't matter who does the build.

> Proprietary software comes as a binary blob, they'll not give a rat's behind 
> about there no longer being a -devel package for the library they're building 
> against, they can build on another distribution, build on an old version of the 
> distribution, build their own version of the library etc., only they need 
> the -devel package anyway, the user only gets the readily-linked blob. They'll 
> keep using obsolete libraries as long as they can get away with it

Beg your pardon?  I see no reason to believe this.  They used what you 
put in the distribution to build their binary just as I do with source 
builds, expecting the binary to continue to work.  If you are going to 
break an interface you need to provide some lead time with an 
appropriate way to fix it.

> because that 
> way, with the same blob, they can also service ancient obsolete distributions 
> and (most importantly to them) "enterprise" distributions, and removing 
> the -devel package will do nothing to stop them from doing that.

Why do you think that it is any more important to a vendor than it is to 
me to be able to run the same binary across different Linux 
distributions?  If I wanted to recompile everything on every machine, 
I'd be using gentoo exclusively.

> Free Software, on the other hand, usually comes as source code. So, if the code 
> doesn't compile against the latest version of the library, you (the user) need 
> the -devel package for the compat library to be able to still build that 
> software. Now of course, you can in principle fix the Free Software to build 
> (unlike a proprietary blob), but in practice this isn't always so easy.

The question is, do you want to support running existing binaries for a 
different length of time than building new binaries with a deprecated 
API?  Personally I see no reason to ever break an existing binary if 
there is any possible choice and don't object to keeping the -devel's 
too, but I can see where you might want to phase out the use of the old 
API in new builds.

-- 
   Les Mikesell
    lesmikesell at gmail.com