>> Would a new tree like he's proposing have to be embedded only? > > Embedded-only is a bit strong. But I'm of the opinion that trying to > have a single tree designed to cover both embedded / small systems and > desktops and servers is considerably more work than having two trees.
Well I would hope it would become a general purpose build system, to cover embedded & desktop systems alike. I think use flags have the potential to be _very_ powerful indeed, allowing a single package tree to be used for embedded (with minimum flags set) and full-blown desktop systems alike. virtuals also help. virtual/sh becomes bash on desktop or busybox on embedded for example. I'd also like ebuilds to be more "binary package aware" and have a set of attributes describing them, a kind of signature: package category package name package version package revision use flags architecture (normal Gentoo arch: amd64/arm/etc) cpu (The target cpu the package is compiled for: i386, i686, k8, xscale, armv6, etc) runtime dependency list I think the runtime dependency list might get pretty complicated. If the dependency is a shared library, the package may need to specify an exact version it was linked against if other versions aren't binary compatible. It might also have to list the use flags each dependency was built against too. So I ask my system to install package X. The package management system then knows it needs a package matching the name, maybe the version, use flags, etc. Once it knows the matching criteria it has several options: It can build the package itself. It can ask another build server to build it or it can download a pre-built package, maybe even from a P2P system like bit torrent (assuming you can search using a hash of the package signature, not the package itself). This is probably all pipe dreams, but it's fun to dream. :-) Cheers, Tom _______________________________________________ paludis-user mailing list [email protected] http://lists.pioto.org/mailman/listinfo/paludis-user
