Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[William Hubbs]

On Tue, Apr 21, 2020 at 07:50:13AM +0200, Michał Górny wrote:
> On Mon, 2020-04-20 at 16:04 -0500, William Hubbs wrote:
> > Your proposal seems to completely go against how the go ecosystem operates,
> > but if you can come up with a proof-of-concept for how it would work
> > without forcing a lot of busy work on us that would never get accepted
> > upstream, I'll take a look.
> >
>
> Define 'busy work'.
 
 Busy work, to me at least, is work that generates a large amount of
overhead compared to the gain it offers the distro and will never be
accepted by upstream.

> Is doing things right 'busy work' vs taking shortcuts?

This depends on what you think "doing things right" or "taking
shortcuts" mean. For example, I have had discussions with maintainers who
are fine with writing patches to fix issues without reporting the issues
upstream. Personally, I disagree with this approach.

> Is it 'busy
> work' that I'm putting a lot of effort into fixing Python packages?
> Should I just last rite them all and tell people to use virtualenv?
 
This gets into the other issue being discussed on the thread, but I have
heard people say that yes you should. All we really need in portage is
the base python tools -- the language, maybe pip and maybe setuptools
and portage itself, then everything else should be installed via pip.

> Is testing packages 'busy work'?  I suppose it's all easier when you
> just silently include 240 dependencies without testing a single one of
> them and call it a day.  Sure, you run some tests on the final package.
> Leaves 240 untested, some of them likely failing tests and requiring
> 'busy work' to fix them.
 
In general I would say no, but I have run into tests that do not tollerate
portage's sandbox, tests that take hours or days to run, or tests that
require root privs. We don't force those kinds of tests to be run in src_test.

> Is security support 'busy work'?  I suppose it's all easier when you
> ignore them problem and let security team deal with it (except they
> won't).  Sure, you can assume that when vulnerability is discovered, all
> upstreams will eventually learn of it, update their bundled dependencies
> and *maybe* inform people that their code might have been indirectly
> vulnerable (but would they do the 'busy work' of discovering whether it
> affected them or not?).
 
In my experience, the security team doesn't write patches to fix
vulnerabilities, so what they do wouldn't be any different in this case.

> I realize Go is not isolated here.  It's just brought as one major
> example.  Rust is no better.  All these shiny 'write and forget'
> languages share the same problem.  Pay for some work hours, get
> a working product, deploy it and forget unless customers want more
> features.
>
> Today these languages are still young and the problems can be considered
> largely theoretical.  But some day -- well, unless all the cool kids
> manage to move on to next shiny new language before then -- this will be
> a major catastrophe.

We can talk about theoretical issues in languages all day, but if we are
going to do that we also have to talk about how terrible and permissive
c is. You can google things like "security in c" and you will find that
since it allows you to do exactly what you want, it is a major
catastrophe in terms of security, but we accept new applications in c
without any questions.

Also, what about the nightmare that is php?

In short, I don't see any reason to bikeshed about theoretical issues in
languages.

The way I see Go and Rust specifically is, more and more things are
being written in these languages, and if we don't accept them, we will
become irrelivent fast.

William