| 1 |
On Tue, 2009-01-13 at 12:58 +0000, Frank Schwidom wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> im searching for a tool, which can create an ebuild of every download |
| 5 |
> location. Is there any known tool? |
| 6 |
|
| 7 |
Although your description itself is a bit ambiguous I'll assume you |
| 8 |
meant: Given download location A is there a tool which I could pass A as |
| 9 |
a parameter and have it automatically create an ebuild for it. |
| 10 |
|
| 11 |
This requirement has a number of problems: |
| 12 |
|
| 13 |
1. The tool has no way of knowing what the download is or does. It |
| 14 |
could probably get that info from the README (if there is one), |
| 15 |
but that's human-readable free text and is not easily |
| 16 |
machine-readable. |
| 17 |
2. The tool would need to know the license. Again this can kinda |
| 18 |
be automated if there is a COPYING file, but you have the same |
| 19 |
restrictions as above. |
| 20 |
3. The tool would need to know compile-time and run-time |
| 21 |
dependencies. Assuming you also want to automate that, the |
| 22 |
system must at least know the download locations of its |
| 23 |
dependencies. This is almost impossible to automate. |
| 24 |
4. The tool would need to know how to build the package. There are |
| 25 |
many ways to do this (autoconf, cmake, xmkmf, eggs, gems, etc.). |
| 26 |
And all these utilities have their quirks which cannot be known |
| 27 |
to an automated tool. |
| 28 |
5. The system would need to know what patches, USE flags, CFLAGS, |
| 29 |
configure options to use for the build process. The system must |
| 30 |
also know how to "massage" these options so that they fit into |
| 31 |
the overall Gentoo way of doing things. |
| 32 |
6. The system must know what steps to perform in the "install" and |
| 33 |
"post-install" process. This varies from package to package and |
| 34 |
the only true way of knowing is through trial and error. |
| 35 |
|
| 36 |
OTOH, portage comes with a lot of tools to help "automate" ebuild |
| 37 |
writing. They have sandbox, the portage API, automagically unpacking |
| 38 |
archives in many different formats, automated patching, the mirror:// |
| 39 |
syntax, .eclasse's for common tasks/schemes, etc. etc. All the stuff |
| 40 |
that *can* be easily automated has already been automated. |
| 41 |
|
| 42 |
So yes, one would write a tool to half-ass do what you want, and you |
| 43 |
will spend as much time, if not more, wrangling with the |
| 44 |
automated .ebuild to actually get it to work. That's why package |
| 45 |
maintainers make the big bucks ;-) |
| 46 |
|
| 47 |
-a |
Archives