Luca Barbato wrote: > Some items I have in wishlist > > - LRDEPEND link runtime dep (I need to link against that in order to run)
I heartily concur with a link dependency, since it's such a fundamental relationship between packages: if A links to B we need to recompile A when the ABI for B changes. How useful is the distinction between runtime vs buildtime in that respect? (I can't see the point of linking to something if it's never used at runtime.) > - BDEPEND build dep (I need those tools in order to build) > Agreed. I'd hope LDEPEND and BDEPEND could cover all current DEPEND uses. Either you depend on something to be installed as you link to its headers and use it at runtime, or you need the tool to build, eg make. (RDEPENDs with no linkage, and hence no requirement to be installed at build-time, and PDEPENDs to break circular chains are the ones I know about.) But I don't know how that interacts with || DEPENDs. wrt SUGGEST et al, I don't see why those can't be kept separately in metadata.xml, if labelling isn't implemented, since they're only of use for package selection, not depgraph resolution (as I understand it). > - arch/ctarget support in deps (same way you have use deps) > Interesting idea. > - explicit ctarget support in the package manager emerge --cross=target > something. > Definitely, at least as much as we can do with the standard variables and GNU make. So not everything will cross-compile, that's to be expected. It would be cool to tie that into the tinderbox stuff that solar and bonsaikitten have done, so that testing could be automated. > - tools to explicitly manipulate sets > I must be missing something with these: they just seem like lists of packages (which you might want updated together, or compiled with the same set of flags etc.) That kind of stuff is more to do with scripting afaict, than the core package manager. (eg using predefined files for any and all configuration before compiling, and then resetting once the set is built. Recovery issues aren't so bad if the user knows the machine has crashed and runs the program to reset stuff before anything else is emerged.) > long time ideas: > > - support cross, multiarch, multilib in a saner and seamless way > Yeah, even if it means building everything in a chroot, for development libs at least. http://tldp.org/HOWTO/Multi-Distro-Dev/use.html (old) reminds me of this; I found it the other day and it looked a lot like stuff we do in Gentoo chroots. -- [EMAIL PROTECTED] mailing list
