On Tue, Jul 15, 2008 at 1:58 PM, Tiziano Müller <[EMAIL PROTECTED]> 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. > > -- > [email protected] mailing list > > -- [email protected] mailing list
