Re: [gentoo-dev] rfc: kubernetes packaging

2020-09-15 Thread William Hubbs
On Mon, Sep 14, 2020 at 12:30:48PM +0200, Marc Schiffbauer wrote:
> * William Hubbs schrieb am 14.09.20 um 00:39 Uhr:
> > All,
> > 
> > I would like to get some thoughts on kubernetes packaging.
> > 
> > When I started maintaining it in Gentoo, it was packaged as 7 ebuilds
> > (one per executable), and only one of them was marked stable.
> > 
> > Since we normally do not split up monorepos into separate packages, I
> > started moving everything over to one kubernetes ebuild.
> > Now a bug has
> > been opened which has a good case for kubeadm being a package on its
> > own, so I have done that [1].
> > 
> > I need to know the best way to proceed, so I'll throw out a couple
> > of questions:
> > 
> > 1) should I bring back the split packages and lastrites
> > sys-cluster/kubernetes?
> > 
> > 2) should I just bring back other split packages that need to be split
> > as I find them?
> > 
> > What do folks think would be the best way for us to package Kubernetes?
> 
> 
> Interesting.
> 
> So it seems like at least kubeadm and kube-apiserver need to be in 
> seperate packages.
> 
> I am not a kubernetes guy, but would SLOTting be an option? Like 
> postgresql for example where you need both versions, old a new to do 
> database migration.

I'm not really interested in slotting; that becomes complicated really
quickly -- renaming all of the binaries to version-specific names
writing an eselect module, etc.

> If this is not an option I would say this is a case for split package 
> and perhaps a meta-package bringing all of them together.

Thinking about it more, the split packages are going to be the best
setup. However, a meta package would only be valuable if all parts of
kubernetes are needed on the same machine, and that isn't the case most
of the time from what I've been told.

If folks think that single case justifies one, let me know.
My thought is that the meta package, if I create one, should only have a
two level version number and use * dependencies to match all package
versions in that range.

What do others think? is it worth a meta package for the case of having
all kubernetes binaries on one machine? If so, what do you think about
my suggestion of the minor versions for the meta package?

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: kubernetes packaging

2020-09-14 Thread Marc Schiffbauer
* William Hubbs schrieb am 14.09.20 um 00:39 Uhr:
> All,
> 
> I would like to get some thoughts on kubernetes packaging.
> 
> When I started maintaining it in Gentoo, it was packaged as 7 ebuilds
> (one per executable), and only one of them was marked stable.
> 
> Since we normally do not split up monorepos into separate packages, I
> started moving everything over to one kubernetes ebuild.
> Now a bug has
> been opened which has a good case for kubeadm being a package on its
> own, so I have done that [1].
> 
> I need to know the best way to proceed, so I'll throw out a couple
> of questions:
> 
> 1) should I bring back the split packages and lastrites
> sys-cluster/kubernetes?
> 
> 2) should I just bring back other split packages that need to be split
> as I find them?
> 
> What do folks think would be the best way for us to package Kubernetes?


Interesting.

So it seems like at least kubeadm and kube-apiserver need to be in 
seperate packages.

I am not a kubernetes guy, but would SLOTting be an option? Like 
postgresql for example where you need both versions, old a new to do 
database migration.

If this is not an option I would say this is a case for split package 
and perhaps a meta-package bringing all of them together.

-Marc


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature