1 |
2007/10/19, Duncan <1i5t5.duncan@×××.net>: |
2 |
> |
3 |
> Beso <givemesugarr@×××××.com> posted |
4 |
> d257c3560710190236q3de96984h39a5a092c30b4528@××××××××××.com, excerpted |
5 |
> below, on Fri, 19 Oct 2007 11:36:53 +0200: |
6 |
> |
7 |
> >> Talking about which... does paludis have proper binary package support |
8 |
> >> yet? [...] Portage's FEATURES=buildpkg is my favorite underdocumented |
9 |
> >> power-user portage feature |
10 |
> |
11 |
> > i don't know of that option being supported. i currently use the 0.24.6 |
12 |
> > from august and that don't seem to list that feature. what does that |
13 |
> > feature in portage?! |
14 |
> |
15 |
> Simply put, it automatically creates tarballed binary packages every time |
16 |
> it emerges something, storing those binary packages by default in |
17 |
> $PORTDIR/packages. That way, should you ever need to remerge that |
18 |
> package-version (say on another machine if you have more than one, or if |
19 |
> you need to revert to an old version because the new version you just |
20 |
> merged doesn't work for some reason), you can do so using emerge -- |
21 |
> usepackage (or --usepackageonly), and it'll grab the binary package you |
22 |
> created the first time, merging it much faster since it doesn't have to |
23 |
> recompile anything. |
24 |
> |
25 |
> IOW, except for the first time you merge a package, it's as if you were |
26 |
> using a binary distribution, except you created and customized the |
27 |
> binaries yourself, using Gentoo's usual features. Of course, the first |
28 |
> time, the package is compiled as it normally is, so there's no direct |
29 |
> advantage there -- but it can still be useful. |
30 |
> |
31 |
> Obviously, the folks that will get the most use out of this are the folks |
32 |
> running several similarly configured machines, same USE flags, etc, since |
33 |
> they can then compile once and merge the same binary package on all their |
34 |
> machines. However, it's quite useful even if you run only a single |
35 |
> machine, as I do here. As I said, it's helpful if you need to remerge a |
36 |
> package for some reason. I've reinstalled from my binpkgs once after a |
37 |
> problem with disk corruption, and it goes MUCH faster. Also, because the |
38 |
> packages are basically tar.bz2s with a bit of extra metadata glued onto |
39 |
> the end, they can be browsed with your favorite archiver (I use mc, as I |
40 |
> do for many of my sysadmin tasks), and it's easy to retrieve just a |
41 |
> single file, say a config file you screwed up and want to start over |
42 |
> with. The binpkgs are also useful for comparing the contents of packages |
43 |
> between versions -- I've filed and had fixed a couple bugs because new |
44 |
> versions ended up missing some file or another, for some reason, caught |
45 |
> because once I figured out something was wrong, it was easy to compare |
46 |
> the files in an older working version with the files in the newer broken |
47 |
> version. |
48 |
> |
49 |
> The format also allows one to fix a broken portage or python. Consider |
50 |
> how you'd emerge a package if your package manager is broken. With |
51 |
> automatically created tarballs, it's easy. Simply backup any config |
52 |
> files you want to save, and untar the working version directly on top of |
53 |
> the live root filesystem. (Or, if it's /really/ broken, and tar and/or |
54 |
> bzip2 are dead as well, boot your recovery disk and use the tar and bzip2 |
55 |
> from there to do the job.) |
56 |
> |
57 |
> The metadata glued onto the tarball includes the ebuild itself, and that |
58 |
> can also be handy. What do you do if you use a package that gets removed |
59 |
> from the tree (for example, xmms)? Well, as long as you still have the |
60 |
> binpkg around, you still have a copy of the ebuild, and can copy it to |
61 |
> your overlay and continue to use it from there, even rebuilding if |
62 |
> necessary (say if you upgrade gcc), even after the copy in the tree is |
63 |
> long gone. |
64 |
> |
65 |
> So it's not just the binary packages, useful enough in their role as |
66 |
> backups as it is, but the fact that the data in those packages can still |
67 |
> be accessed with ordinary tools like tar and bzip2, that makes portage's |
68 |
> binpkgs so useful. If an alternative package manager supported binpkgs, |
69 |
> I'd hope it used something equally accessible with standard tools. |
70 |
|
71 |
|
72 |
this could be an interesting feature and could have you do a full system |
73 |
backup. |
74 |
|
75 |
> i'm using paludis for a speed reason. portage is really really slow and |
76 |
> > it makes you die before determining deps. it's awful in that terms. |
77 |
> |
78 |
> I've found that to be true only for the first "cold cache" run, when it |
79 |
> has to read everything in from disk. Once the data is in cache, portage |
80 |
> is MUCH faster. With a gig of memory, it should be in cache pretty much |
81 |
> as long as you are using it, tho if you go a few days between using |
82 |
> portage, or if you reboot, the data will probably be flushed from cache |
83 |
> and need to be read in from slow disk once again. With a couple gigs, |
84 |
> it's likely you'll only have to do that initial portage run once, and |
85 |
> after that it'll remain in memory until the next reboot. With the 8 gigs |
86 |
> of memory I have... lets just say I normally don't worry about it, tho |
87 |
> that first emerge --pretend world I run does take a bit. Of course, |
88 |
> syncing also takes a bit, but that's not too terribly often either, |
89 |
> compared to the number of times you might actually run emerge in a |
90 |
> session. |
91 |
> |
92 |
> So speed isn't the problem for me it is for some. |
93 |
|
94 |
|
95 |
i have a notebook that i usually shut down more than 3-4 times/day and the |
96 |
chache problem for me is fundamental. i don't have to wait for portage |
97 |
almost 7minutes for a world preview update while paludis does it in less |
98 |
than 2min. |
99 |
|
100 |
> i |
101 |
> > foud out paludis which has a great speed and that seems to give a lot of |
102 |
> > debug infos and that has a more modular approach when compared to |
103 |
> > portage. the last useful thing is that i with portage i used to get some |
104 |
> > times compilation errors that would go away when resuming; this thing |
105 |
> > don't happen almost anytime with paludis. |
106 |
> |
107 |
> The more modular is of course good on its own merits, as is faster, tho I |
108 |
> explained that's not a big problem for me here. As for compilation |
109 |
> errors, I don't tend to get any of those that go away on resume, altho |
110 |
> there was a bit of an order resolving problem in ~arch portage for a few |
111 |
> months that caused a few issues. However, I'm pretty religious about |
112 |
> running --newuse and --deep (both run by default on my --update world |
113 |
> runs), and --depclean and revdep-rebuild as well. That likely has a lot |
114 |
> to do with it, as my dependencies are going to be quite a bit cleaner |
115 |
> than someone who doesn't routinely practice "good package hygiene". =8^) |
116 |
> |
117 |
> In any case, as I said, unless a package manager has good binary package |
118 |
> support, there's little chance of me seriously considering it. Thus the |
119 |
> question, since the lack of such binary package support is what ended my |
120 |
> initial paludis investigation back then. Of course, different strokes |
121 |
> for different folks and all that, and what works so well for me may |
122 |
> indeed be intolerable for you, so as they say, YMMV. |
123 |
|
124 |
|
125 |
fortunately i still run both packages and have paludis --report the state of |
126 |
the system then portage to depclean and see if there are differences. i |
127 |
didn't find to have problems of orphaned or other problems of package |
128 |
management. the one interesting function that i'd like to test is the |
129 |
parallel compilation feature, which i happened to find by chance in the |
130 |
forum. a patch that allows portage to compile more packages at the same time |
131 |
if the second package compiled does not trigger an installation of the first |
132 |
one. for example i could compile gimp and knetworkmanager at the same time |
133 |
if i had a good processor. |
134 |
|
135 |
-- |
136 |
> Duncan - List replies preferred. No HTML msgs. |
137 |
> "Every nonfree program has a lord, a master -- |
138 |
> and if you use the program, he is your master." Richard Stallman |
139 |
> |
140 |
> -- |
141 |
> gentoo-amd64@g.o mailing list |
142 |
> |
143 |
> |
144 |
|
145 |
|
146 |
-- |
147 |
dott. ing. beso |