| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On April 12, 2004 06:45 am, Alexander Gretencord wrote: |
| 5 |
> On Sunday 11 April 2004 13:55, Tom St Denis wrote: |
| 6 |
> > I think a cool function [which I didn't see in the latest portage |
| 7 |
> > release] is a "snapshot" and restore set of functionality. e.g. you can |
| 8 |
> > snapshot the current install set and later restore (by adding/removing |
| 9 |
> > packages) as required. |
| 10 |
> |
| 11 |
> What exactly do you mean by that? What irritates me is that "by |
| 12 |
> adding/removing packages". If you just want a list of all installed |
| 13 |
> packages you can already get it. What I'd understand by snapshotting is |
| 14 |
> really packaging a set of packages and their deps. Kind of a '-b' but after |
| 15 |
> merging. |
| 16 |
|
| 17 |
Well Ideally a command that simply emits a list of installed packages is what |
| 18 |
I'm talking about. But specifically, it emits the list [and say GZIPs it at |
| 19 |
the same time] into a db of "restore points". |
| 20 |
|
| 21 |
So as another poster said I could do say |
| 22 |
|
| 23 |
emerge restore "11/04/04" |
| 24 |
|
| 25 |
If I installed something today that I didn't like. The trick is to make this |
| 26 |
painless for the user so the user won't scream in horror and go install |
| 27 |
Windows. |
| 28 |
|
| 29 |
> > Also any plans to optimize the portage files? 80k small files amounts to |
| 30 |
> > huge waste of space. |
| 31 |
> |
| 32 |
> Depends on your filesystem. With certain filesystems you could adjust the |
| 33 |
> blocksize for /usr/portage/ to a smaller value (with a larger value |
| 34 |
> for /usr/portage/distfiles of course) or use reiserfs with tail packing on. |
| 35 |
|
| 36 |
Oh, ok so I'll just format my disk, reinstall Gentoo from scratch so that I |
| 37 |
can not waste 200M of space on 80k small files. |
| 38 |
|
| 39 |
That's not really user friendly. Could have done a JAR like setup for each |
| 40 |
dir of the tree. e.g. all of app-text be one huge ZIP file [with no |
| 41 |
compression]. Such a setup might be a little slower to add/remove files but |
| 42 |
would waste less space. |
| 43 |
|
| 44 |
The idea would make a little sense though in practice. When I do "emerge |
| 45 |
sync" instead of fetching 1000s of small files I just check the timestamp on |
| 46 |
the directory zips and download them wholesale. [Ok so maybe compression |
| 47 |
makes sense here]. |
| 48 |
|
| 49 |
That way as a user I don't have to worry about inserting/deleting files from a |
| 50 |
zip [which would take a while] only the server has todo it. In fact the |
| 51 |
server could still use the "many files" approach and just zip on the fly when |
| 52 |
a user syncs. |
| 53 |
|
| 54 |
I know that would make things a bit more complicated since mirrors update via |
| 55 |
"sync" as well. I guess you could just have two types of portage trees. |
| 56 |
e.g. "packaged" and "straight" or something like that. End users would use |
| 57 |
the "packaged" type [e.g. zip per category] and mirrors would use straight |
| 58 |
[e.g. all 80k files]. |
| 59 |
|
| 60 |
Anyways, I'm just throwing out ideas here. Using the zip approach makes sense |
| 61 |
for end users. First, it makes for faster syncing [less smaller files means |
| 62 |
fewer metadata commands] and wastes much less space [and would be faster |
| 63 |
since the kernel could cache it quicker!]. |
| 64 |
|
| 65 |
Tom |
| 66 |
-----BEGIN PGP SIGNATURE----- |
| 67 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 68 |
|
| 69 |
iD8DBQFAeoWDsP+tEsHHY0ARAg/dAJwMV7cUdGl8GJ/qA0StH9RFwRajCACfWqL4 |
| 70 |
hv++FVTFxDrzXKCKrrN1s4Y= |
| 71 |
=wEEo |
| 72 |
-----END PGP SIGNATURE----- |
| 73 |
|
| 74 |
-- |
| 75 |
gentoo-dev@g.o mailing list |
Archives