1 |
> > > > That is when you compile it on another machine then install it on the |
2 |
> > > > laptop. The -K option comes to mind here. |
3 |
> > > > |
4 |
> > > |
5 |
> > > Which is what I think the OP was talking about. If you install one of the |
6 |
> > > *-bin packages from portage, you are protected by the checksums in the |
7 |
> > > ebuild digest. But if you create a binary package repository, there is |
8 |
> > > currently no means of applying the same protection. So if you are |
9 |
> > > administering machines at different locations and want to keep a single |
10 |
> > > binary package repository so you only build once (remember, production |
11 |
> > > servers may not have gcc installed), there is no means of checking that |
12 |
> > > the downloaded package has not been tampered with. This protection |
13 |
> > > applies to ebuilds and distfiles but cannot be applied to packages you |
14 |
> > > build yourself. |
15 |
> > > |
16 |
> > |
17 |
> > But he was responding to me mentioning Redhat and Mandrake which are |
18 |
> > binary based. Maybe I took his original point wrong. |
19 |
> |
20 |
> Exactly :) |
21 |
> Neil correctly translated my pseudo-English to what I actually meant. I |
22 |
> don't want to make Portage binary based. I just want to make Portage's |
23 |
> binary package support more conveniently usable on big networks. |
24 |
|
25 |
I don't think there is any shortage of great ideas here. Can we get |
26 |
into specifics on how projects are born and become successful? |
27 |
|
28 |
So, what would need to happen for one of these projects to take off |
29 |
would be one or more people to be in charge of it and organize it, and |
30 |
they recruit as many people as possible to work on the project along |
31 |
with them? Does that recruitment generally take the form of |
32 |
volunteers finding the project as opposed to the project finding |
33 |
volunteers? Any light to shed on this process for me? |
34 |
|
35 |
- Grant |
36 |
-- |
37 |
gentoo-user@g.o mailing list |