| 1 |
On Tue, 16 May 2006 19:57:13 -0400 |
| 2 |
Mark Loeser <halcy0n@g.o> wrote: |
| 3 |
|
| 4 |
> All three are great |
| 5 |
> ideas, but we should only support the one that is official for Gentoo, |
| 6 |
> and not make any changes to the tree. (Note: changes here is any |
| 7 |
> modification or addition of files in the tree for the sole purpose of |
| 8 |
> working with an alternate package manager) |
| 9 |
|
| 10 |
It looks to me like the best way forward is for the alternative package |
| 11 |
managers to host their own overlays containing their profile(s) and |
| 12 |
whatever else they want to try, until such time as they become |
| 13 |
officially supported. I don't see that this makes things difficult for |
| 14 |
the alternatives; the only thing they would need to do is sync the |
| 15 |
additional overlay, which would be easy enough. |
| 16 |
|
| 17 |
It would also encourage the alternatives to either minimise any |
| 18 |
effects on ebuilds, or to get any desired changes to the rules |
| 19 |
on writing ebuilds accepted into the official manager. |
| 20 |
|
| 21 |
> Either way, I think this is something we should hold off on for now, |
| 22 |
> and have the council decide upon. |
| 23 |
|
| 24 |
It's unlikely we will see a sensible result from the discussion on |
| 25 |
g-dev@, since the issue degenerates far too easily into a portage v. |
| 26 |
others debate despite the best efforts of some. Still, you never |
| 27 |
know... |
| 28 |
|
| 29 |
> We shouldn't just make these |
| 30 |
> changes without having some discussion taking place (the flamewar on |
| 31 |
> g-dev@ is not a discussion, and is only a small minority of people |
| 32 |
> giving their two cents). |
| 33 |
> |
| 34 |
> Whatever the decision is, the addition of another package manager |
| 35 |
> makes QA harder to do since we have to consider all of them. Adding |
| 36 |
> a new package manager and saying we don't support it, nor are we sure |
| 37 |
> if we will ever support it, does not seem acceptable at all to me. |
| 38 |
> The decision should be made if we plan on supporting it so we can |
| 39 |
> work on actually supporting it, or if this should be a completely |
| 40 |
> separate project and they can work on their own to make changes to |
| 41 |
> ebuilds which support their own functionality. |
| 42 |
> |
| 43 |
|
| 44 |
|
| 45 |
-- |
| 46 |
Kevin F. Quinn |
Archives