| 1 |
On Thu, 2004-04-29 at 16:12, Daniel Robbins wrote: |
| 2 |
> > Sure, it sounds good, but will it ever get off the ground? |
| 3 |
> > I'm not convinced that this idea will take off... |
| 4 |
> |
| 5 |
> OK, we were talking about "GRP" -- the official, current definition here, |
| 6 |
> which is already off the ground, clearly works, and used by lots of people. |
| 7 |
> Several years ago, many Gentoo developers were against GRP as it exists |
| 8 |
> today, and it was a large uphill battle to push for the creation of binary |
| 9 |
> packages. What we are talking about is whether a possibility exists for |
| 10 |
> Gentoo to totally regress to that original state, with next to no pre-built |
| 11 |
> packages were available for our users. At this point, as Sven points out, |
| 12 |
> there would be a great amount of resistance to GRP being dropped entirely |
| 13 |
> (many users rely on GRP, the installer project is going strong, etc.) |
| 14 |
> |
| 15 |
> The stuff in GLEP 26 should be called something else, since it seems like |
| 16 |
> we're all getting confused about what everyone else is talking about. And I |
| 17 |
> agree with you in that it may not get off the ground any time soon. This |
| 18 |
> shouldn't prevent interested parties in trying to figure out how to get it |
| 19 |
> ("it" being binary packages to keep your system up-to-date) to work, though. |
| 20 |
> And I can certainly understand why infrastructure may not want to host a |
| 21 |
> comprehensive binary package update repository, since that could potentially |
| 22 |
> involve a huge commitment of both CPU and storage resources. So huge, in |
| 23 |
> fact, that it may be technically impossible to do as an official effort |
| 24 |
> under the Gentoo Foundation itself. |
| 25 |
> |
| 26 |
> But I think the incremental binary update _technology_ is worth having. A |
| 27 |
> lot of companies and educational institutions are trying to figure out how |
| 28 |
> to deploy Gentoo and keep all their machines up-to-date. If incremental |
| 29 |
> binary package updates are an option for them, I'm sure they'd appreciate |
| 30 |
> it. Now, I am not saying that _we_ would provide the binary packages to |
| 31 |
> them. We don't need to host the binary packages -- Gentoo can simply create |
| 32 |
> the technology, explain how to use it, and then interested companies and |
| 33 |
> universities can build their own package sets for their own internal use. |
| 34 |
> Then they have a very efficient way to keep their catalyst-built Gentoo |
| 35 |
> systems up-to-date. |
| 36 |
> |
| 37 |
> I bet that a handful will make their binary packages available to the |
| 38 |
> public. For some organizations, this would be appealing because additional |
| 39 |
> users would result in more QA over time, more bug reports, and the ability |
| 40 |
> to improve their binary package sets faster. I think that this is more |
| 41 |
> likely to happen in an academic setting, though. |
| 42 |
> |
| 43 |
> Just some ideas... |
| 44 |
> |
| 45 |
> Regards, |
| 46 |
> |
| 47 |
> Daniel |
| 48 |
> |
| 49 |
> |
| 50 |
> -- |
| 51 |
> gentoo-releng@g.o mailing list |
| 52 |
|
| 53 |
Well said Daniel - |
| 54 |
GRP is here to stay because it is a user-popular viable install option. |
| 55 |
What I proposed in my document are the incremental updates. If we choose |
| 56 |
to go this route (which means I would completely rewrite that glep), |
| 57 |
then I like the way that Daniel laid out - make the techology available, |
| 58 |
document it, and let the users use it if they want to. |
| 59 |
|
| 60 |
Let me know what you think. |
| 61 |
|
| 62 |
Cheers, |
| 63 |
//zhen |
| 64 |
-- |
| 65 |
John Davis |
| 66 |
Gentoo Linux Developer |
| 67 |
<http://dev.gentoo.org/~zhen> |
| 68 |
|
| 69 |
---- |
| 70 |
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc> |
| 71 |
Fingerprint: 2364 71BD 4BC2 705D F338 FF70 6650 1235 1946 2D47 |
Archives