| 1 |
On Tue, Jul 15, 2008 at 1:58 PM, Tiziano Müller <dev-zero@g.o> wrote: |
| 2 |
> Patrick Börjesson wrote: |
| 3 |
> |
| 4 |
>> On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: |
| 5 |
>>> Marius Mauch wrote: |
| 6 |
>>> |
| 7 |
>>> > As a result of Cardoes earlier mail we talked a bit about possible |
| 8 |
>>> > solutions in #gento-portage, and I suggested to let portage |
| 9 |
>>> > automatically inject the deps based on SRC_URI pattern matching. |
| 10 |
>>> > A mapping of extensions and their unpack deps would be kept in the tree |
| 11 |
>>> > (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' |
| 12 |
>> [snip] |
| 13 |
>>> > So, is this something ebuild maintainers would like in general, or does |
| 14 |
>>> > such a feature cause you nightmares? |
| 15 |
>>> |
| 16 |
>>> Yes. I think that's something which should be done manually. |
| 17 |
>> |
| 18 |
>> Indeed, the correct solution would be to state the deps manually in each |
| 19 |
>> ebuild that requires the dep. But in this case it would mean adjusting |
| 20 |
>> the DEPEND string of pretty much the entire tree. Until such measures |
| 21 |
>> are stated required, this would be a good middle ground, no? |
| 22 |
> no. How about just introducing the new deps on their next version or |
| 23 |
> revision bump? (I assume that more than half of the packages would be fixed |
| 24 |
> within the next half year and that's more than fast enough). |
| 25 |
|
| 26 |
Why would you do a bunch of manual work when you can script it easily |
| 27 |
with few false positives? |
| 28 |
Doubly so when false positives are relatively cheap; adding an extra |
| 29 |
dep on a package you probably |
| 30 |
already have installed won't hurt much and those it does hurt can file |
| 31 |
bugs for the RESTRICT and/or |
| 32 |
explicitly state the dep. |
| 33 |
|
| 34 |
We could alternatively just use this automatic system to automatically |
| 35 |
modify DEPEND in the majority of ebuilds |
| 36 |
and work the bugs out that way. |
| 37 |
|
| 38 |
I think doing this entirely manually is just a waste of your time though ;) |
| 39 |
|
| 40 |
-Alec |
| 41 |
|
| 42 |
|
| 43 |
> |
| 44 |
>> |
| 45 |
>> The same thing would apply to gcc if all "real" depends were to be |
| 46 |
>> required in all ebuilds, but that would pretty much have to be manually |
| 47 |
>> stated since the PM wouldn't be able to judge that by automatic |
| 48 |
>> measures. This, on the other hand, can (at least partially) be handled |
| 49 |
>> automatically for the ebuild-devs on the PM side of things. |
| 50 |
> That's a different thing: |
| 51 |
> A dependency on gcc just ensures that gcc is installed not that it is |
| 52 |
> actually used to build a package. |
| 53 |
> And for such a dependency we'd need new ways to express deps since gcc is |
| 54 |
> only needed when building packages not when it gets installed from a |
| 55 |
> binpkg. |
| 56 |
> But this is not an argument for an automagic dep. |
| 57 |
> |
| 58 |
> -- |
| 59 |
> gentoo-dev@l.g.o mailing list |
| 60 |
> |
| 61 |
> |
| 62 |
-- |
| 63 |
gentoo-dev@l.g.o mailing list |
Archives