On Mon, 30 Jul 2007 17:01:10 +0100
"Tom Cooksey" <[EMAIL PROTECTED]> wrote:
> I suspect the problems I've had with portage lie more in the package
> tree & ebuilds than portage itself (in which case Paludis wont help?).

Largely correct. Paludis can do better than Portage, but it's still
constrained by the tree.

> Anyway, what I want is the ability to define my target's profile &
> configuration (make.conf) and simply do an "emerge system" to build
> everything.

Paludis supports multiple separate configuration directories via the
--environment switch.

> * In addition to the "host" root files system hierarchy, I foresee 2
> others:
>        - A toolchain hierarchy, including build-time dependency
> packages (a.k.a. portage SYSROOT)

Yupyup. A normal ebuild repository should cover that.

>        - A target hierarchy, where packages are installed (a.k.a.
> portage ROOT)

That'd be a standard VDB repository with root set.

> * Ability to only include files required at run-time in the target
> hierarchy, i.e. no .a or .h files

Paludis can do install file filtering via hooks. In 0.26 this will be
quite a lot more flexible than it is in 0.24.

> * Possibly a 3rd hierarchy, if required, for configuration & profile
> (a.k.a. PORTAGE_CONFIGROOT)

That's all covered much more elegantly via specpath.

> * Ability to take a totally empty toolchain & target hierarchy and do
> an "emerge system" to generate a toolchain & bootable root filesystem
> image.

You're limited by the ebuilds there. They pretty much assume that you
already have a working toolchain and you're creating a more or less
identical toolchain.

> * Separate build system from distribution, so people can use
> Fedora/Debian/Cygwin/Whatever, install the build system and use it to
> make target root filesystems.

Again, you're limited by ebuilds there. Some ebuilds rely upon
utilities having being patched in a particular way, which won't be the
case.

> * Ability to use 3rd party toolchains. I've not really thought about
> how this could be done too much, perhaps using ASSUME_PROVIDED type
> defines for gcc/libc.

Again, ebuilds. There's no standard way of doing toolchain things for
ebuilds.

> Anyway, how well do you think these requirements fit with Paludis?

Paludis can do a much better job of things than Portage, but it's still
limited to what ebuilds support. Gentoo developers write ebuilds based
around certain assumptions about the underlying system; you may have to
create your own tree rather than using the Gentoo repository if you
don't like these assumptions.

-- 
Ciaran McCreesh

Attachment: signature.asc
Description: PGP signature

_______________________________________________
paludis-user mailing list
[email protected]
http://lists.pioto.org/mailman/listinfo/paludis-user

Reply via email to