On Tue, Jul 15, 2008 at 1:58 PM, Tiziano Müller <dev-zero@g.o> wrote:
> Patrick Börjesson wrote:
>
>> On 2008-07-15 21:40, Tiziano Müller uttered these thoughts:
>>> Marius Mauch wrote:
>>>
>>> > As a result of Cardoes earlier mail we talked a bit about possible
>>> > solutions in #gento-portage, and I suggested to let portage
>>> > automatically inject the deps based on SRC_URI pattern matching.
>>> > A mapping of extensions and their unpack deps would be kept in the tree
>>> > (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )'
>> [snip]
>>> > So, is this something ebuild maintainers would like in general, or does
>>> > such a feature cause you nightmares?
>>>
>>> Yes. I think that's something which should be done manually.
>>
>> Indeed, the correct solution would be to state the deps manually in each
>> ebuild that requires the dep. But in this case it would mean adjusting
>> the DEPEND string of pretty much the entire tree. Until such measures
>> are stated required, this would be a good middle ground, no?
> no. How about just introducing the new deps on their next version or
> revision bump? (I assume that more than half of the packages would be fixed
> within the next half year and that's more than fast enough).

Why would you do a bunch of manual work when you can script it easily
with few false positives?
Doubly so when false positives are relatively cheap; adding an extra
dep on a package you probably
already have installed won't hurt much and those it does hurt can file
bugs for the RESTRICT and/or
explicitly state the dep.

We could alternatively just use this automatic system to automatically
modify DEPEND in the majority of ebuilds
and work the bugs out that way.

I think doing this entirely manually is just a waste of your time though ;)

-Alec


>
>>
>> The same thing would apply to gcc if all "real" depends were to be
>> required in all ebuilds, but that would pretty much have to be manually
>> stated since the PM wouldn't be able to judge that by automatic
>> measures. This, on the other hand, can (at least partially) be handled
>> automatically for the ebuild-devs on the PM side of things.
> That's a different thing:
> A dependency on gcc just ensures that gcc is installed not that it is
> actually used to build a package.
> And for such a dependency we'd need new ways to express deps since gcc is
> only needed when building packages not when it gets installed from a
> binpkg.
> But this is not an argument for an automagic dep.
>
> --
> gentoo-dev@g.o mailing list
>
>
--
gentoo-dev@g.o mailing list