| 1 |
2006/10/11, Daniel Pielmeier <daniel.pielmeier@××××××××××.com>: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> I recognized this some time ago! |
| 5 |
> |
| 6 |
> When my system is up to date "emerge -pvuND world" shows me: |
| 7 |
> |
| 8 |
> > emerge -pvuND world |
| 9 |
> > |
| 10 |
> > These are the packages that would be merged, in order: |
| 11 |
> > |
| 12 |
> > Calculating world dependencies... done! |
| 13 |
> > |
| 14 |
> > Total size of downloads: 0 kB |
| 15 |
> |
| 16 |
> Which is normal because an up to date system doesn't have to download |
| 17 |
> anything. But when i add the emptytree option "emerge -pveuND world" i |
| 18 |
> get this (output reduced): |
| 19 |
> |
| 20 |
> > emerge -pveuND world |
| 21 |
> > |
| 22 |
> > These are the packages that would be merged, in order: |
| 23 |
> > |
| 24 |
> > ... |
| 25 |
> > Calculating world dependencies ..... ....... done! |
| 26 |
> > [ebuild N ] sys-devel/binutils [2.16.1-r3] USE="nls |
| 27 |
> > -multislot -multitarget -test -vanilla" 109 kB |
| 28 |
> > ... |
| 29 |
> > [ebuild N ] net-dialup/ppp [2.4.3-r16] USE="gtk ipv6 |
| 30 |
> > pam -activefilter -atm -dhcp -eap-tls -mppe-mppc -radius" 55 kB |
| 31 |
> > ... |
| 32 |
> > |
| 33 |
> > Total size of downloads: 164 kB |
| 34 |
> |
| 35 |
> So why are there appearing some apps now for which portage has to |
| 36 |
> download something? Using eix on sys-devel/binutils and net-dialup/ppp |
| 37 |
> tells me that i have exactly those ebuilds listed above installed. |
| 38 |
> |
| 39 |
> I think that there have been made changes to this ebuild without |
| 40 |
> increasing the version number. For example binutils from 2.16.1-r3 to |
| 41 |
> 2.16.1-r4. So portage doesn't upgrade this package although there have |
| 42 |
> been changes. Or is there a portage option i don't know until now which |
| 43 |
> i have to use for getting this apps updated. Am i guessing right in any |
| 44 |
> of this cases or is this another problem with portage? |
| 45 |
|
| 46 |
Maybe is that only minor changes like build-fix patches... |
| 47 |
|
| 48 |
For example, let's say you've a x86 system and a package foobar-1.0 |
| 49 |
compiles just fine on your system but not on amd64. |
| 50 |
If developper provides a patch to make foobar-1.0 compile fine on |
| 51 |
amd64 he might not change the ebuild version number because the bug |
| 52 |
was "blocking" the update and the amd64 users *will* notice the |
| 53 |
changes. And the x86 won't have to recompile the soft just in order to |
| 54 |
apply an *unneeded* patch... (IMHO) |
| 55 |
|
| 56 |
regards, |
| 57 |
|
| 58 |
Boris. |
| 59 |
> |
| 60 |
> Thanks in advance, |
| 61 |
> |
| 62 |
> Daniel |
| 63 |
> -- |
| 64 |
> gentoo-user@g.o mailing list |
| 65 |
> |
| 66 |
> |
| 67 |
|
| 68 |
|
| 69 |
-- |
| 70 |
Quiconque me parle de Dieu en veut à ma bourse ou à ma liberté. |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-user@g.o mailing list |
Archives