| 1 |
On Donnerstag 22 Juli 2010, covici@××××××××××.com wrote: |
| 2 |
> Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 3 |
> > On Wednesday 21 July 2010 23:14:35 covici@××××××××××.com wrote: |
| 4 |
> > > > This is a painful process. It's enough to drive a sysadmin to drink |
| 5 |
> > > > or (god forbid), to Windows. Portage can't help as the ebuild |
| 6 |
> > > > doesn't know what you have installed. So you must run a script to go |
| 7 |
> > > > and dig out all this crap for you. |
| 8 |
> > > > |
| 9 |
> > > > |
| 10 |
> > > > |
| 11 |
> > > > All I can say is, every day I get down on my knees and offer thanks |
| 12 |
> > > > that perl is not slotted. |
| 13 |
> > > |
| 14 |
> > > But portage should be sensible enough to either run this for you, or |
| 15 |
> > > stop emerging -- I had a lot of trouble during the last update where I |
| 16 |
> > > kept getting errors and I emerged a couple of them before I knew I had |
| 17 |
> > > to run perl-cleaner. |
| 18 |
> > |
| 19 |
> > You haven't thought this through and haven't consider how portage knows |
| 20 |
> > what to do. |
| 21 |
> > |
| 22 |
> > Portage doesn't do it because portage can't. |
| 23 |
> > You want portage to do it != portage can do it. |
| 24 |
> > |
| 25 |
> > Consider this: |
| 26 |
> > |
| 27 |
> > [I] dev-lang/perl |
| 28 |
> > |
| 29 |
> > Installed versions: 5.12.1-r1(23:11:24 21/07/10)(berkdb gdbm -build |
| 30 |
> > - |
| 31 |
> > |
| 32 |
> > debug -doc -ithreads) |
| 33 |
> > |
| 34 |
> > [I] dev-perl/DateManip |
| 35 |
> > |
| 36 |
> > Installed versions: 5.56(19:39:11 17/07/10)(-test) |
| 37 |
> > |
| 38 |
> > When I upgraded perl to 5.12.1-r1, DateManip was not upgraded. Why not? |
| 39 |
> > because it's version number did not change and that is the ONLY thing |
| 40 |
> > portage considers. DateManip depends on perl, not on |
| 41 |
> > =perl-whatever-I-used-to-have |
| 42 |
> > |
| 43 |
> > So portage does not know of the link between these two things and cannot |
| 44 |
> > take them into account. Portage won't be expanded anytime soon either - |
| 45 |
> > you saw how long it took for perl-cleaner to run, must portage go |
| 46 |
> > through something like that with every emerge? |
| 47 |
> > |
| 48 |
> > Similarly, one could say portage should detect rev-dep breakage. |
| 49 |
> > Surprise! It doesn't. revdep-rebuild does that (comparable to |
| 50 |
> > perl-cleaner) and you know how long that takes to run. |
| 51 |
> > |
| 52 |
> > So you wasted some time with an upgrade. Well that's a shame. But we |
| 53 |
> > don't care much, especially if you don't read the elog messages. If you |
| 54 |
> > feel that portage should does this automagically, and have a plan to |
| 55 |
> > make it run REAL quick, and have proven, workable, debugged, solid, |
| 56 |
> > stable patches, then I'm sure Zac would be very happy indeed to hear |
| 57 |
> > from you. |
| 58 |
> > |
| 59 |
> > In the meantime, read the elog messages. |
| 60 |
> |
| 61 |
> But I could not read the elog messages, |
| 62 |
|
| 63 |
you can either read them with elogv or have portage send them per email |
| 64 |
whereever you want. So you can read them, while emerging other stuff. |
Archives