Summary: | double downloads (beta2 and rc1) for kdebase, kdepim, kdemultimedia | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Benno Schulenberg <bensberg> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Benno Schulenberg
2005-03-09 03:50:34 UTC
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... |