1 |
On 29/07/14 12:00, Rich Freeman wrote: |
2 |
> On Tue, Jul 29, 2014 at 6:52 AM, behrouz khosravi <bz.khosravi@×××××.com> wrote: |
3 |
>> well chromium was just an example. I just think that when there is a version |
4 |
>> upgrade, a patch should be enough. |
5 |
> For things like backports you're fairly likely to only get a patch. |
6 |
> However, for an upstream version change (which chromium seems to have |
7 |
> every other week) you're probably going to get a full tarball. |
8 |
> |
9 |
>> I have read that portage is migrating to git, but I guess I got it wrong, |
10 |
>> because I thought that the source codes will be maintained using git too. |
11 |
>> However why not? why not use git for source maintenance too? |
12 |
> Portage probably will migrate to git at some point, but when it does |
13 |
> you'll probably not notice a thing. |
14 |
> |
15 |
> Gentoo doesn't maintain the source to chromium - upstream does. In |
16 |
> some cases Gentoo doesn't even redistribute the source (licensing |
17 |
> issues). For chromium Google publishes a tarball on googleapis.com |
18 |
> and Gentoo mirrors it. |
19 |
> |
20 |
> There has been talk about creating some kind of source repository for |
21 |
> things like patches/etc, but that isn't going to really change when we |
22 |
> distribute patches vs upstream tarballs. Generally speaking upstream |
23 |
> tarballs are preferred over patches to keep things simple. With what |
24 |
> we do now you know you're basically getting chromium as upstream |
25 |
> distributes it. If we were to just mirror chrome-25 and 300 binary |
26 |
> diffs to patch it up to the current version nobody could keep track of |
27 |
> it all, and while you'd save some space on each upgrade your first |
28 |
> install might involve downloading 10GB of diffs unless we went even |
29 |
> further and had a variety of full vs incremental files. This has been |
30 |
> discussed in terms of having portage on squashfs and just doing it for |
31 |
> our own stuff looks to be fairly painful, let alone doing it for every |
32 |
> upstream out there. |
33 |
> |
34 |
> Rich |
35 |
> |
36 |
The big issue I see in doing this would be that if you for example don't |
37 |
have libreoffice or something then you would need to download the source |
38 |
and the patches and then crucially keep a copy everywhere so that it can |
39 |
be patched in the future. the way it works currently portage fetches |
40 |
from a suitable mirror everything it needs and then cleans up after |
41 |
itself, so /usr/portage remains of a certain size. |
42 |
|
43 |
if we were all to download all sources and then have portage only fetch |
44 |
diffs then we would all need to have an equivalent of a full slakware |
45 |
DVD kit on hand which starts getting very unruly very easily - even if |
46 |
we only wanted a minimal gentoo with iproute2. |
47 |
|
48 |
to save yourself the downloads you might want to look into setting up |
49 |
your own PORTAGE_BINHOST that you can redistribute from, but be wary |
50 |
that different devices may require different compile options, so you can |
51 |
sacrifice speed for compatibility by using more generic makeoptions |
52 |
|
53 |
hth |