Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 84616 - double downloads (beta2 and rc1) for kdebase, kdepim, kdemultimedia
Summary: double downloads (beta2 and rc1) for kdebase, kdepim, kdemultimedia
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-09 03:50 UTC by Benno Schulenberg
Modified: 2007-02-09 17:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benno Schulenberg 2005-03-09 03:50:34 UTC
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.
Comment 1 Dan Armak (RETIRED) gentoo-dev 2005-03-09 13:06:36 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.
Comment 2 Dan Armak (RETIRED) gentoo-dev 2005-03-09 13:07:36 UTC
(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.)
Comment 3 Benno Schulenberg 2005-03-13 13:27:58 UTC
> 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.
Comment 4 Dan Armak (RETIRED) gentoo-dev 2005-03-14 10:03:41 UTC
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.
Comment 5 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-14 10:37:51 UTC
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.
Comment 6 Dan Armak (RETIRED) gentoo-dev 2005-03-14 12:20:06 UTC
Does SRC_URI support || (a b c) syntax? I just tried and it didn't work.
Comment 7 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-14 12:29:45 UTC
Earlier portage versions didn't, but the current one should. >> Bug 16159
Comment 8 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-14 12:32:03 UTC
Ah no, that was only about conditional stuff. I implied it would be supported, but if you tested it, you'll be probably right.
Comment 9 Benno Schulenberg 2005-03-14 13:48:35 UTC
> 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?
Comment 10 Dan Armak (RETIRED) gentoo-dev 2005-03-19 10:57:55 UTC
> 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?
Comment 11 Charlie Shepherd (RETIRED) gentoo-dev 2007-02-09 17:08:09 UTC
Doesn't look like we're gonna change the behaviour any time soon...