Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-14 Thread Rich Freeman
On Sun, Sep 13, 2020 at 11:52 PM Kent Fredric  wrote:
>
> But when you file a bug, you rely on bugzilla being maintained by
> Gentoo Infra, not some 3rd party.
>

I think the Council will need to consider where it wants to draw the
lines on something like this.  Here is my sense of how these sorts of
things come about:

1.  Somebody sees an opportunity for improvement and writes some code.
They interface it on their own with git/bugzilla/whatever and host it
on their own systems.  They use it for a while and improve it.

2.  They start to advertise it and call for testers.  This is nothing
more than a list post at the start.  It is completely optional.  A few
people start using it and find that it is helpful.

3.  It is still optional, but since it is helpful the 10% of the devs
who do 90% of the work in the relevant area (like arch teams/etc)
adopt it, which means that 90% of the work is using the new tool,
still self-hosted by the dev.  It might or might not have any source
published.

4.  The devs who are using the tool are also the ones maintaining all
the documentation for the official workflows, and they update it to
reflect what they're actually doing.  It might still be optional.  (In
fact, as far as I can tell from reading the docs nattka is still
optional - you could still just CC arch teams and so on yourself -
heck, arch teams can stabilize things even if you don't file a bug
though this is unlikely to happen much.)

5.  At some point somebody notices that 80% of the problems come from
the 10% of the work that isn't doing things the new way, and the new
way stops being optional.

Maybe somebody closer to these tools might want to correct something
above.  However, as an observer this is how these things seem to
evolve - it is a very bazaar-like methodology.

Keep in mind that rules don't make things happen - they prevent things
from happening.  The hope behind a rule is that if you dam off
something suboptimal the enthusiasm travels down some other path and
doesn't just die off.  So, where do you build the dam above?  Do you
let steps 1-4 happen and draw the line at step 5, which might just
mean that we accept the 80% of the problems that come from it being
optional until infra hosts it?  Do we draw the line all the way up at
1 and block any use of APIs in ways that are not explicitly approved?
Do we block it at step 4, so the arch team is using nattka for 90% of
the cases, and they just trade notes via email and nobody else knows
what they're doing because the wiki reflects a process nobody actually
follows?

I realize that I'm mostly pointing out things that can go wrong.

I don't think anybody would say that it is better not having infra
maintaining critical infra.  The problem is that the infra team
probably isn't going to officially host stuff way back at step 1.  A
random dev can't write a script and ask infra to start running it and
bug them 3 times a day to do a pull from their git repo.  Infra is
probably going to wait until something closer to step 3-4 before they
get involved, which means the tool is already being used for a
substantial amount of work.  I'm not sure if we even have a defined
process for getting new tools like these onto infra, or how we do
config/change management in these cases.

The council can say "don't use non-infra-hosted services as part of
essential processes" but what does that actually mean?  Does that mean
going up to step 3, so 90% of your arch testing bugs are going through
nattka, but it just isn't documented on the wiki?  Does it mean going
up to step 2, so some portion of them are - if so how do you prevent
it from going from 10% to 90% if the new tool works better?  Does it
mean not interfering at all with 1-5 but imploring infra and the
service maintainers to figure something out?  If the service isn't
expensive to run, those maintaining the service might not see much
benefit in moving it over, and infra is of course always
manpower-constrained.

It might be easier to take smaller steps, such as having a policy that
"any call for devs to use/test a new tool/service, or any service that
automatically performs transactions on bugzilla, must be FOSS, and the
link to the source must be included in the initial communication, and
it must be clear what version of the code is operating at any time."
That is a pretty low barrier to those creating tools, though it
doesn't address the infra concern.  However, it does mean that infra
is now free to fork the service at any time, and reduces the bus
factor greatly.

-- 
Rich



Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-14 Thread Michał Górny
Dnia September 13, 2020 11:21:28 AM UTC, Andrew Savchenko  
napisał(a):
>On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
>> Thanks to David Michael for the initial patch and upstream fixes.
>> 
>> Signed-off-by: Michał Górny 
>> ---
>>  eclass/acct-group.eclass | 16 +++-
>>  eclass/acct-user.eclass  | 16 +++-
>>  2 files changed, 30 insertions(+), 2 deletions(-)
>> 
>> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
>> index 5550e4a2fb10..dc1562974870 100644
>> --- a/eclass/acct-group.eclass
>> +++ b/eclass/acct-group.eclass
>> @@ -80,7 +80,7 @@ S=${WORKDIR}
>>  
>>  
>>  # << Phase functions >>
>> -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
>> +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
>>  
>>  # @FUNCTION: acct-group_pkg_pretend
>>  # @DESCRIPTION:
>> @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
>>  fi
>>  }
>>  
>> +# @FUNCTION: acct-group_src_install
>> +# @DESCRIPTION:
>> +# Installs sysusers.d file for the group.
>> +acct-group_src_install() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +insinto /usr/lib/sysusers.d
>> +newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
>> +printf "g\t%q\t%q\n" \
>> +"${ACCT_GROUP_NAME}" \
>> +"${ACCT_GROUP_ID/#-*/-}"
>> +)
>> +}
>> +
>>  # @FUNCTION: acct-group_pkg_preinst
>>  # @DESCRIPTION:
>>  # Creates the group if it does not exist yet.
>> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
>> index e82f3c56dbbe..f9772c3cb111 100644
>> --- a/eclass/acct-user.eclass
>> +++ b/eclass/acct-user.eclass
>> @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
>>  # @FUNCTION: acct-user_src_install
>>  # @DESCRIPTION:
>>  # Installs a keep-file into the user's home directory to ensure it
>is
>> -# owned by the package.
>> +# owned by the package, and sysusers.d file.
>>  acct-user_src_install() {
>>  debug-print-function ${FUNCNAME} "${@}"
>>  
>> @@ -321,6 +321,20 @@ acct-user_src_install() {
>>  # created yet
>>  keepdir "${ACCT_USER_HOME}"
>>  fi
>> +
>> +insinto /usr/lib/sysusers.d
>> +newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
>> +printf "u\t%q\t%q\t%q\t%q\t%q\n" \
>> +"${ACCT_USER_NAME}" \
>> +"${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
>> +"${DESCRIPTION//[:,=]/;}" \
>> +"${ACCT_USER_HOME}" \
>> +"${ACCT_USER_SHELL/#-*/-}"
>> +if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
>> +printf "m\t${ACCT_USER_NAME}\t%q\n" \
>> +"${ACCT_USER_GROUPS[@]:1}"
>> +fi
>> +)
>>  }
>
>Why these files are installed unconditionally?
>
>Of course we have a common "small files" policy that USE flags
>should not control small files in packages, such rule was designed
>for common packages where:
>  1) small files are insignificant disk usage compared to a whole
>package;
>  2) an average package takes significant time to rebuild and mass
>rebuild will cause problems during USE flip.
>
>While both arguments are valid for a common packages which provide
>real software, this is not true for very special acct-* packages:
>  1) They may (and usually do) have zero size of installed files,
>this makes sysusers.d stuff an infinite times larger than a
>whole typical acct-* package (it will still be much larger if one
>will consider size of new passw/group records).

Did you realize that your mail is infinite times larger than if you never wrote 
it? 

>  2) acct-* packages are very fast to rebuild, so such price will
>be small compared to other changes necessary when USE="systemd" is
>being flipped.

The price of reading it is also infinite times larger. Not to mention actually 
addressing it.

>
>So it will be reasonable to add USE="systemd" to acct-* eclasses
>to control the changes proposed above.
>
>Best regards,
>Andrew Savchenko


--
Best regards, 
Michał Górny



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


Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-14 Thread David Seifert
On Sun, 2020-09-13 at 14:21 +0300, Andrew Savchenko wrote:
> On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
> > Thanks to David Michael for the initial patch and upstream fixes.
> > 
> > Signed-off-by: Michał Górny 
> > ---
> >  eclass/acct-group.eclass | 16 +++-
> >  eclass/acct-user.eclass  | 16 +++-
> >  2 files changed, 30 insertions(+), 2 deletions(-)
> > 
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 5550e4a2fb10..dc1562974870 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -80,7 +80,7 @@ S=${WORKDIR}
> >  
> >  
> >  # << Phase functions >>
> > -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> > +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
> >  
> >  # @FUNCTION: acct-group_pkg_pretend
> >  # @DESCRIPTION:
> > @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
> > fi
> >  }
> >  
> > +# @FUNCTION: acct-group_src_install
> > +# @DESCRIPTION:
> > +# Installs sysusers.d file for the group.
> > +acct-group_src_install() {
> > +   debug-print-function ${FUNCNAME} "${@}"
> > +
> > +   insinto /usr/lib/sysusers.d
> > +   newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> > +   printf "g\t%q\t%q\n" \
> > +   "${ACCT_GROUP_NAME}" \
> > +   "${ACCT_GROUP_ID/#-*/-}"
> > +   )
> > +}
> > +
> >  # @FUNCTION: acct-group_pkg_preinst
> >  # @DESCRIPTION:
> >  # Creates the group if it does not exist yet.
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> > index e82f3c56dbbe..f9772c3cb111 100644
> > --- a/eclass/acct-user.eclass
> > +++ b/eclass/acct-user.eclass
> > @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
> >  # @FUNCTION: acct-user_src_install
> >  # @DESCRIPTION:
> >  # Installs a keep-file into the user's home directory to ensure it
> > is
> > -# owned by the package.
> > +# owned by the package, and sysusers.d file.
> >  acct-user_src_install() {
> > debug-print-function ${FUNCNAME} "${@}"
> >  
> > @@ -321,6 +321,20 @@ acct-user_src_install() {
> > # created yet
> > keepdir "${ACCT_USER_HOME}"
> > fi
> > +
> > +   insinto /usr/lib/sysusers.d
> > +   newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> > +   printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> > +   "${ACCT_USER_NAME}" \
> > +   "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> > +   "${DESCRIPTION//[:,=]/;}" \
> > +   "${ACCT_USER_HOME}" \
> > +   "${ACCT_USER_SHELL/#-*/-}"
> > +   if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> > +   printf "m\t${ACCT_USER_NAME}\t%q\n" \
> > +   "${ACCT_USER_GROUPS[@]:1}"
> > +   fi
> > +   )
> >  }
> 
> Why these files are installed unconditionally?
> 
> Of course we have a common "small files" policy that USE flags
> should not control small files in packages, such rule was designed
> for common packages where:
>   1) small files are insignificant disk usage compared to a whole
> package;
>   2) an average package takes significant time to rebuild and mass
> rebuild will cause problems during USE flip.
> 
> While both arguments are valid for a common packages which provide
> real software, this is not true for very special acct-* packages:
>   1) They may (and usually do) have zero size of installed files,
> this makes sysusers.d stuff an infinite times larger than a
> whole typical acct-* package (it will still be much larger if one
> will consider size of new passw/group records).

Using a multiplicative factor here seems purely for trying to make an
argument. Any filesystem space taken here seems negligible.

>   2) acct-* packages are very fast to rebuild, so such price will
> be small compared to other changes necessary when USE="systemd" is
> being flipped.
> 
> So it will be reasonable to add USE="systemd" to acct-* eclasses
> to control the changes proposed above.

Why not add these paths to INSTALL_MASK to ease the burden on the number
of installed files?

There's another argument to be made: every USE flag added potentially
increases the complexity of the depgraph. Given the tradeoffs, I'm
willing to accept a tiny file more here.