| 1 |
On Sunday 11 March 2007 15:01:27 Steve Long wrote: |
| 2 |
> > I don't know what you mean by making Portage recognize the software |
| 3 |
> > installed this way. Do you want Portage to be able to uninstall and/or |
| 4 |
> > upgrade this software? If so, the simple answer is you it can't do |
| 5 |
> > that. You have to manage the software outside of Portage yourself. |
| 6 |
|
| 7 |
He can if he makes an ebuild for it (or as Neil suggested finds one outside |
| 8 |
the tree). It's not that hard to do. |
| 9 |
|
| 10 |
> [...] package.provided - I used this for that kde-env script that was moved |
| 11 |
> last year, as certain pkgs in the tree still depended on its ebuild, but it |
| 12 |
> had been moved to kde-libs (which it blocked.) I unmerged it to get |
| 13 |
> kde-libs, and put an entry in package.provided for pkgs which still had a |
| 14 |
> dependency on it. Once the tree had all been updated I deleted the entry. |
| 15 |
|
| 16 |
package.provided is certainly not intended to be used to circumvent |
| 17 |
dependencies due to blocks. Not that that has any relevance to this thread |
| 18 |
though. |
| 19 |
|
| 20 |
-- |
| 21 |
Bo Andresen |
Archives