[arch-general] A suggestion for the devs regarding rebuilds

[arch at nezmer.info]

On Sun, Jan 10, 2010 at 01:08:10PM -0500, Jeff Horelick wrote:
> Hey all,
> 
> I have a suggestion to possibly make rebuilds a bit less painful (or
> non-existant). I think this is a good idea because it seems like right now,
> even before there was a new rebuild (ffmpeg/x264) in testing, there's
> already another on the horizon (linjpeg/libpng, and it's a big one) and when
> this isn't the case, there's usually a rebuild, when it leaves testing,
> another rebuild comes in within days  and so on.
> 
> My suggestion would be to do what Debian does and when there's a library
> release with a new soname, bump the old package and "rename" it (or for new
> packages just do it from the start) and make the package name include the
> soname version (like libjpeg7, libpng12, libtorrent-rasterbar4 and so on)
> and when the soname is bumped upstream, just make libjpeg8 or libpng13 or
> libtorrent-rasterbar5. This does clutter the repos a bit, but it pretty much
> negates the need for rebuilds since (i believe) when the new GNOME for
> example is released, it'll automagically build against libjpeg8 and libpng13
> instead of the old ones and eventually, almost no packages will be using the
> old ones. Once the package list for a large rebuild like the libpng/libjpeg
> one is down to 3 or 4 items after like 3 months, you can probably rebuild
> them and pull libjpeg7/libpng12 from the repos.
> 
> This would likely require 2 changes to pacman to implement:
> 1. Pacman would have to know that libpng8 is the newer version of libpng7
> and prompt users to install that (or do it as a upgrade keeping the old
> package).
> 2. Pacman would have to know something was removed from the repo and somehow
> notify the user and possibly give them a [Y/n] to remove it from their
> system. (I personally think this is a good idea to implement anyway).
> 
> -JD

I'm quite sure Debian doesn't do that. IIUC they include older versions of
libraries If other packages need that version specifically.

Your suggestion has a technical flow btw. A situation where a newer package will link
against libfoo8 while a dependency will still link against libfoo7 will
be common. If It's all about reducing rebuild work, Arch should switch
to static linking ;)