| 1 |
On Mon, 2005-03-07 at 18:57 +0200, Martin Schlemmer wrote: |
| 2 |
> > I kind of like this idea, however, I think it's idealistic. Patches need |
| 3 |
> > to be modified very frequently. Especially when we combine multiple |
| 4 |
> > patches and make them all work with USE flags. |
| 5 |
> > |
| 6 |
> > A great deal of our patches really are written specifically work with our |
| 7 |
> > ebuilds. |
| 8 |
> > |
| 9 |
> > What is the real percentage of space usage from compressed or uncompressed |
| 10 |
> > patches? How big of a problem is it? |
| 11 |
> > |
| 12 |
> |
| 13 |
> Also the problem is that especially if you have a rapid changing |
| 14 |
> package, where the patches changes a lot, putting it in distfiles is a |
| 15 |
> pita, as you have to scp it, then wait an hour to 3 depending on how |
| 16 |
> lucky you are, and then only commit. And especially if you forgetful |
| 17 |
> like me, you tend to forget to either come back and commit the new |
| 18 |
> version/revision, or to copy the new tarball to distfiles ... |
| 19 |
|
| 20 |
This was why we were asking for a "packages.gentoo.org" that could |
| 21 |
either be a single or multiple machines. It could even replace |
| 22 |
the /space/distfiles-local, as everything from it could be pushed out to |
| 23 |
be synched to distfiles. This would make them immediately available, |
| 24 |
and would alleviate the problem. Once the main distfiles mirrors got |
| 25 |
the files, they could be deleted from packages.gentoo.org |
| 26 |
|
| 27 |
-- |
| 28 |
Chris Gianelloni |
| 29 |
Release Engineering - Strategic Lead/QA Manager |
| 30 |
Games - Developer |
| 31 |
Gentoo Linux |
Archives