| 1 |
* William Hubbs schrieb am 14.09.20 um 00:39 Uhr: |
| 2 |
> All, |
| 3 |
> |
| 4 |
> I would like to get some thoughts on kubernetes packaging. |
| 5 |
> |
| 6 |
> When I started maintaining it in Gentoo, it was packaged as 7 ebuilds |
| 7 |
> (one per executable), and only one of them was marked stable. |
| 8 |
> |
| 9 |
> Since we normally do not split up monorepos into separate packages, I |
| 10 |
> started moving everything over to one kubernetes ebuild. |
| 11 |
> Now a bug has |
| 12 |
> been opened which has a good case for kubeadm being a package on its |
| 13 |
> own, so I have done that [1]. |
| 14 |
> |
| 15 |
> I need to know the best way to proceed, so I'll throw out a couple |
| 16 |
> of questions: |
| 17 |
> |
| 18 |
> 1) should I bring back the split packages and lastrites |
| 19 |
> sys-cluster/kubernetes? |
| 20 |
> |
| 21 |
> 2) should I just bring back other split packages that need to be split |
| 22 |
> as I find them? |
| 23 |
> |
| 24 |
> What do folks think would be the best way for us to package Kubernetes? |
| 25 |
|
| 26 |
|
| 27 |
Interesting. |
| 28 |
|
| 29 |
So it seems like at least kubeadm and kube-apiserver need to be in |
| 30 |
seperate packages. |
| 31 |
|
| 32 |
I am not a kubernetes guy, but would SLOTting be an option? Like |
| 33 |
postgresql for example where you need both versions, old a new to do |
| 34 |
database migration. |
| 35 |
|
| 36 |
If this is not an option I would say this is a case for split package |
| 37 |
and perhaps a meta-package bringing all of them together. |
| 38 |
|
| 39 |
-Marc |
| 40 |
|
| 41 |
|
| 42 |
-- |
| 43 |
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 |
| 44 |
6E9E CA3E 7BF6 7F97 9BE5 |
Archives