| 1 |
On Saturday 26 April 2008, Mark Knecht wrote: |
| 2 |
|
| 3 |
> I don't buy that it's my issue created by a long time between |
| 4 |
> updates. I could turn on any machine that's sitting in a junk heap or |
| 5 |
> back room somewhere. It hasn't been powered up in a long time. I log |
| 6 |
> in and want to figure out what's in front of me with respect to |
| 7 |
> updates. I type emerge sync and portage deletes files. to me that's |
| 8 |
> just wrong. |
| 9 |
|
| 10 |
Mark, |
| 11 |
|
| 12 |
This might be worth discussing. I know you said "enough of this" later |
| 13 |
on but enough users run into conceptually similar issues to make it |
| 14 |
worth while. Examples: someone needs a specific kernel version for some |
| 15 |
hardware and it goes away from portage or weird video cards where only |
| 16 |
ATIs magic from 2005 actually works. |
| 17 |
|
| 18 |
First, let's look at the real source of the problem: using rsync to |
| 19 |
download the tree. To know what will change or what's new portage needs |
| 20 |
a new tree, and there is no summary for that. It really needs two trees |
| 21 |
to run a diff against and it has to be done locally - the rsync server |
| 22 |
is clueless about what you currently have. So basically to tell you |
| 23 |
what will change, portage has to have a new tree which nukes the old |
| 24 |
stuff... |
| 25 |
|
| 26 |
One could write a dual-portage thingy that replicates what you have then |
| 27 |
does emerge --sync, and also has an --undo fetaure for just in case. |
| 28 |
Ughh. One must take account of the portage db, the metacache and other |
| 29 |
bits as well. |
| 30 |
|
| 31 |
So how about something that creates overlays for you? As a wrapper to |
| 32 |
emerge? It could have options to convert various bits of the current |
| 33 |
system to private overlays, and generate a decent cache to speed things |
| 34 |
up (the current state of affairs will not cache a local overlay by |
| 35 |
default so it's really slow). I'm thinking of these things: |
| 36 |
|
| 37 |
- Install every currently installed ebuild to an overlay, or install |
| 38 |
specific ebuilds or specific categories to an overlay. |
| 39 |
- Copy an installed ebuild and it's entire installed DEPEND tree to an |
| 40 |
overlay - this is for cases where <arb_lib> is not in world but is |
| 41 |
required as a deep dependency of something that is. The user will |
| 42 |
probably not be aware of this dependency and not having that ebuild |
| 43 |
will break stuff. |
| 44 |
- Copy an entire profile to an overlay |
| 45 |
- Copy everything in an installed ebuild's SRC_URI (or all installed |
| 46 |
ebuilds) to a different DISTDIR for safety (think ATI driver downloads |
| 47 |
or kernels here) |
| 48 |
- Remove old ebuilds and profiles from the overlay that you have since |
| 49 |
upgraded |
| 50 |
- Possibly more |
| 51 |
|
| 52 |
Such a script would do the backup you wished you had done for your |
| 53 |
folks, but only the bits you had installed (not everything), then run |
| 54 |
emerge. You get a good compromise between you needing old stuff to be |
| 55 |
around and the dev's perfectly reasonable desire to not have to support |
| 56 |
old stuff not in common use. |
| 57 |
|
| 58 |
It could be implemented one of these ways: |
| 59 |
- a new feature to portage - highly unlikely considering the fear and |
| 60 |
dread that comes with modifying portage in it's current state |
| 61 |
- a new feature to paludis - this might be possible as I believe |
| 62 |
paludis' code design is quite sane |
| 63 |
- a wrapper around emerge (easiest and most likely to benefit the |
| 64 |
largest numbers if interested users) |
| 65 |
|
| 66 |
|
| 67 |
|
| 68 |
-- |
| 69 |
Alan McKinnon |
| 70 |
alan dot mckinnon at gmail dot com |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-user@l.g.o mailing list |
Archives