On Mon, Jan 11, 2010 at 12:53 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick <jdhore1@gmail.com> 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 is one of the single biggest things I hate about apt based distros. The libfoo2/libfoo3/libfoo4 cruft. It's needless.
This doesn't do anything with regards to helping the devs do rebuilds, because packages still need to be rebuilt. It just allows us to take our time - something you DON'T want if you're expecting packages to be up to date.
With every big rebuilds we get new breakage stories. It seems like it's the norm nowadays rather than the exception. I am wondering if it's really only the users that are to blame.. or if Arch is also to blame. Or if Arch was supposed to be an elitist distribution and is victim of its success. More importantly, I am wondering if the sodepends/soprovides proposal would not actually be a more complex solution than the libfoo2/libfoo3/libfoo4 way.