| 1 |
>Hm, I am afraid there is no trivial way to do this, short of collating |
| 2 |
>contents of all these packages in a single ebuild. However this: |
| 3 |
>1. is ugly |
| 4 |
>2. will not work if there are interdependencies within this set of packages |
| 5 |
> |
| 6 |
> |
| 7 |
That is the exactly why I doing this. We plan to deploy the packages |
| 8 |
included that have right interdependencies. |
| 9 |
|
| 10 |
>Well, it should be possible if you split this package in two (and if it is |
| 11 |
>only the downloading part that you want to combine): |
| 12 |
>one downloads and unpacks the meta-tarball that you package yourself (should |
| 13 |
>have src_unpack placing extracted individual tarballs into ${D}/${DISTDIR} |
| 14 |
>and empty scr_compile/install) |
| 15 |
>second just lists the dependencies as mentioned before. |
| 16 |
> |
| 17 |
> |
| 18 |
> |
| 19 |
so you mean something like |
| 20 |
dummy-download-1.0.0.ebuild => contains foo/bar etc |
| 21 |
dummy-extract-1.0.0.ebuild => something like kde-base? |
| 22 |
|
| 23 |
>Although I fail to see why would you want to do something like that. I mean |
| 24 |
>what is the situation when it is better to roll your own meta tarballs rather |
| 25 |
>than fetch individual ones? Well, bittorrent will be more efficient with |
| 26 |
>single large package rather than multiple small ones, but other than that I |
| 27 |
>am quite puzzled :). |
| 28 |
> |
| 29 |
> |
| 30 |
> |
| 31 |
|
| 32 |
The advantage of doing this is viz: |
| 33 |
|
| 34 |
1. QA has to test one huge download and dont have to test different |
| 35 |
scenarios. |
| 36 |
2. You exactly know what packages you are getting in this download |
| 37 |
3. You have to issue one-and-only-one command for upgrade |
| 38 |
|
| 39 |
|
| 40 |
Thanks for all your help, |
| 41 |
|
| 42 |
Ashish |
| 43 |
|
| 44 |
-- |
| 45 |
gentoo-portage-dev@g.o mailing list |
Archives