Today I decided to try the rc1 release of kde-3.4.0, without having tried the betas. To my amazement it downloaded both kdebase-3.4.0-rc1.tar.bz2 and kdebase-3.3.92.tar.bz2, both kdepim-3.4.0-rc1.tar.bz2 and kdepim-3.3.92.tar.bz2, both kdemultimedia-3.4.0-rc1.tar.bz2 and kdemultimedia-3.3.92.tar.bz2. This was the given command: emerge kmail konqueror kbabel kuickshow kaboodle -f This was with all the necessary unmasking lines in package.keywords (~x86) and in package.unmask (>=....._beta). Trying to avoid the double downloads with ">=....._rc1" doesn't work, it complains with 'emerge: there are no ebuilds to satisfy "~kde-base/kcheckpass-3.4.0_rc1"'. So I guess there should be rc1 ebuilds for _all_ KDE packages, even if nothing changed since the preceding version. Reproducible: Always Steps to Reproduce: 1. 2. 3.
This behavior is correct. The split ebuilds whose sources didn't actually change between beta2 and rc1 didn't get rc1 ebuilds. This avoids pointless recompilation. So for (almost?) every tarball (eg kdebase-ver.tar.bz2) some ebuilds are at beta2 and some are at rc1. So you need both tarballs. You can use USE=kdexdeltas to download just the beta2->rc1 xdelta instead of the whole new tarball. However that'll download the alpha1 tarballs and xdeltas all the way to rc1, so if you haven't been using the older prereleases it won't help you much.
(Changing the beta2 ebuilds to use the rc1 tarballs would be a PITA even though the sources are the same. I'd much rather not try to do that.)
> The split ebuilds whose sources didn't actually change between beta2 > and rc1 didn't get rc1 ebuilds. This avoids pointless recompilation. It avoids recompilation only for those that had the beta2, at the cost of double downloads for those who hadn't. I would think that those that used the betas know about 'kdexdeltas', and don't mind an hour or two of extra compilation. What are you going to do for 3.4 final? Are you going to leave some of the ebuilds at rc1 or beta2? If not, then I disagree with marking this bug as 'invalid'. It is quite valid, but you decided not to fix it. Which I can understand: it's only for a week or two. But Gentoo people don't mind compiling, yet some of them do mind their downloading bandwidth.
For 3.4 we've created 3.4.0 ebuilds for all packages, although most of them hadn't actually changed. The reasoning here is that users aren't used to split packages yet and would be too confused if on a new system 'emerge kde' installed packages tagged 3.4.0_rc1 and even beta2. In the future, even first stable releases (eg 3.5.0) will probably only have the really changed ebuilds updated. As for the compile time/download tradeoff, in my experience very very few users would think compiling >50% of KDE (in late bugfix releases like 3.3.2 this is easily >80%) is cheaper than downloading ~100MB. Feel free to prove me wrong. Unfortunately I don't see a way to pass this tradeoff choice to the user via a USE flag or something. (Other than kdexdeltas which we already provide.) So I have to choose one way and this is what I've chosen. Possibly this should be resolved as CANTFIX, but it's certainly not a WONTFIX.
Dan, how about SRC_URI = || ( final rc1 betaX ) etc.. If a fitting tarball exists, there won't be an additional one downloaded. It'd be the users problem, if he's too fast deleting already fetched tarballs and has to compile again. I'm not sure if this is worth the hassle or would complicate the meta eclass too much.
Does SRC_URI support || (a b c) syntax? I just tried and it didn't work.
Earlier portage versions didn't, but the current one should. >> Bug 16159
Ah no, that was only about conditional stuff. I implied it would be supported, but if you tested it, you'll be probably right.
> In the future, even first stable releases (eg 3.5.0) will probably > only have the really changed ebuilds updated. But imagine the users coming new to Gentoo in (say) half a year, wanting to install KDE, and seeing it downloads kdebase-3.5.0.tbz, and then for some unchanged lib downloads kdebase-3.4.2.tbz, and for some unchanged plugin downloads kdebase-3.4.1.tbz. I'm afraid you're going to get a bunch of angry words. If this SRC_URI="(a || b || c)" thing could be gotten to work, that would be the perfect solution. Otherwise the ebuilds for the parts that haven't changed since the previous version would have to include a test and simply do nothing if they detect the previous is installed. This avoids the needless recompiling for those that do an update, and having all the ebuilds up-to-date avoids the needless downloads for the new-comers. Including such a test is of course ugly, but is it feasible?
> If this SRC_URI="(a || b || c)" thing could be gotten to work, that > would be the perfect solution. Doubtful, there probably won't be many usecases if at all beyond our own. Something like the recent talk about server-side diff generation for all distfiles is a more likely eventuality. > Otherwise the ebuilds for the parts > that haven't changed since the previous version would have to include > a test and simply do nothing if they detect the previous is installed. Impossible. The contract for ebuilds is that they aren't affected by what packages are installed(*), because you might be e.g. preparing binary packages for other systems, and determinism in the compile stage script is generally a good thing. (*) Unless you really, really can't avoid it. This probably isn't one of those cases. This avoids the needless recompiling for those that do an update, and having all the ebuilds up-to-date avoids the needless downloads for the new-comers. Including such a test is of course ugly, but is it feasible?
Doesn't look like we're gonna change the behaviour any time soon...
