| 1 |
On Sat, Nov 26, 2011 at 4:28 PM, Fabian Groffen <grobian@g.o> wrote: |
| 2 |
> On 26-11-2011 01:54:35 +0000, Arfrever Frehtes Taifersar Arahesis wrote: |
| 3 |
>> commit: 1d4ac47c28706094230cb2c4e6ee1c1c71629aa0 |
| 4 |
>> T> Org> |
| 5 |
>> AuthorDate: Sat Nov 26 01:52:49 2011 +0000 |
| 6 |
>> Commit: Arfrever Frehtes Taifersar Arahesis <arfrever <AT> gentoo <DOT> org> |
| 7 |
>> CommitDate: Sat Nov 26 01:52:49 2011 +0000 |
| 8 |
>> URL: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1d4ac47c |
| 9 |
>> |
| 10 |
>> dblink.mergeme(): Merge files in alphabetic order. |
| 11 |
> |
| 12 |
> What's the advantage of this? I don't really like to pay for sorting a |
| 13 |
> potentially huge list just for some eye-candy. (That's omitted by |
| 14 |
> default these days anyway...) |
| 15 |
> Any other opinions on this one? |
| 16 |
> |
| 17 |
|
| 18 |
If it should be sorted[1], it should really be sorted in the reverse |
| 19 |
order of distfile-download size. That would be extremely useful on |
| 20 |
systems with slow internet connections. Too many times have I sat |
| 21 |
waiting for libreoffice-bin to download while a webkit-gtk recompile |
| 22 |
waits in the queue. |
| 23 |
|
| 24 |
We already have the information during dependency resolution with |
| 25 |
--verbose, and it costs very little. Besides, sorting even 30,000 |
| 26 |
entries (if you're merging every ebuild in portage) should not take |
| 27 |
more than a few secs. |
| 28 |
|
| 29 |
1. I'm obviously assuming that dep nodes that do not depend on each |
| 30 |
other would be sorted |
| 31 |
|
| 32 |
-- |
| 33 |
~Nirbheek Chauhan |
| 34 |
|
| 35 |
Gentoo GNOME+Mozilla Team |
Archives