GOAL DEFINITION for duplicate bug postings. 1. All the creation of distinct portage trees that provide software in conjuction with the main tree or with a subset of trees. 2. Configuation files via /etc/portage that allow for 'emerge sync' to perform the updates for each tree in turn. This allows for Third-Party trees to be developed and deployed with minimal interaction on behalf of the Third-Party.
*** Bug 56415 has been marked as a duplicate of this bug. ***
Nice; that's much simpler than what I said. There still should be some library and/or command that allows for the creation and maintenance of (1) as well as the alteration of (2), rather than forcing third parties to reimplement said functionality again and again and again (which ups the chances for one vendor to supply a buggy implementation). One possibility would be to allow each vendor to create a vendor tree, named after the vendor (or vendor ID), in which each software vended from said vendor would place its ebuilds. This would avoid excessive numbers of trees as well as naming collisions (as unlikely as those are).
/etc/portage/repositories/ is probably a good place for it. I believe Genone has at least a partial implementation of this floating around somewhere. The implementaiton needs to be hammered out as it can get a little hazy if the repos are independent or arbitrarily defined. One file, which determines the repo name, source, username, password, configs, etc... mycomputer /etc/portage/repositories # cat risky_software # Risky Software, Inc. -- End User Configuration URI="rsync://risky_software.com/gentoo" USERNAME="spork" PASSWORD="knife" OVERLAYS="gentoo-portage postalsoft" mycomputer /etc/portage/repositories #
Importent would be to give the user some information, which overlay is used when emerging a particular ebuild (maybe adding the ebuild header, too), to prevent bugs.g.o being cluttered with reports regarding external/unofficial ebuilds.
*** Bug 28796 has been marked as a duplicate of this bug. ***
This is not going in stable.
*** Bug 159740 has been marked as a duplicate of this bug. ***
