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
On 4/21/20 6:50 AM, Michał Górny wrote:
> 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
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
On 4/20/20 5:48 PM, Georg Rudoy wrote:
>
>> I've learned the hard way that it discourages you from doing all the
>> things that I just said high-quality software should do.
>
> Again, ranging from one-off pseudo-scripts that I had to come back to
> after a couple of years, to quite complicated
On 4/20/20 5:25 PM, Patrick McLean wrote:
>
> Please explain how we are actively making things worse for you? We
> are contributing useful packages to the tree, we are doing the work
> and we are doing it in the way that makes the most effective use of
> our time. We simply do not have time to be
пн, 20 апр. 2020 г. в 17:38, Michael Orlitzky :
> Diamond dependencies manifest mainly in delayed version
> bumps, while slyfox does all the work to make sure that the things
> already in the tree will work with the new version. This requires lots
> of careful updates to neighboring packages, and
On 4/20/20 5:05 PM, Georg Rudoy wrote:
>
>> If upstream absolutely insists on minor-version dependencies, then you
>> either tolerate it conflicting with everything else, or leave it out of
>> the tree. You probably shouldn't even be packaging a library whose API
>> is distinguishable across
On Mon, 20 Apr 2020 17:03:50 -0400
Michael Orlitzky wrote:
> On 4/20/20 4:19 PM, Patrick McLean wrote:
> >
> > My co-workers are not the only ones adding/maintaining go packages in the
> > tree, please do not single out any groups, and let's all work to make
> > Gentoo the best it can be.
> >
пн, 20 апр. 2020 г. в 16:51, Michael Orlitzky :
> Except that Haskell as a research language tends to inspire more "fire and
> forget" software.
I'd say this is not the case for the last few years, but that's maybe
just my own impression from interacting with
> (And Haskell works better in
On Mon, Apr 20, 2020 at 03:23:15PM -0400, Michael Orlitzky wrote:
> > Are you volunteering to do the work to package go packages? The people
> > doing the work generally get to decide how that work gets done, and which
> > approach they would like to take. The upstream situation makes it very
>
On 4/20/20 4:19 PM, Patrick McLean wrote:
>
> My co-workers are not the only ones adding/maintaining go packages in the
> tree, please do not single out any groups, and let's all work to make Gentoo
> the best it can be.
>
Everyone else is just using the eclass that your coworkers defended
On 4/20/20 8:27 PM, Rich Freeman wrote:
> IMO it isn't really worth worrying about, because right now the main
> limitation seems to be a lack of people working on projects, not 25
> devs who each want to re-implement go their own way...
This is another reason I think is so important the overlays
On 4/20/20 4:21 PM, Georg Rudoy wrote:
> вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky :
>> But please quit looking to Go as an example of anything
>> anyone should be doing.
>
> On a somewhat related note, I'd like to take this chance to ask about
> packaging haskell software, which has
вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky :
> But please quit looking to Go as an example of anything
> anyone should be doing.
On a somewhat related note, I'd like to take this chance to ask about
packaging haskell software, which has somewhat similar issues:
1. Two different executables
On Mon, 20 Apr 2020 15:23:15 -0400
Michael Orlitzky wrote:
> On 4/20/20 2:58 PM, Patrick McLean wrote:
> >>
> >> You keep saying that, but the fact that dev-go/* is filled with trash
> >> that has your name on it prevents anyone else from doing a better job.
> >>
> > Ad-hominen attacks are
On Mon, Apr 20, 2020 at 2:07 PM Michael Orlitzky wrote:
>
> On 4/20/20 1:31 PM, Patrick McLean wrote:
> >> Simply having things in ::gentoo does not affect anyone who does not
> use them.
> >
>
> You keep saying that, but the fact that dev-go/* is filled with trash
> that has your name on it
On 4/20/20 2:58 PM, Patrick McLean wrote:
>>
>> You keep saying that, but the fact that dev-go/* is filled with trash
>> that has your name on it prevents anyone else from doing a better job.
>>
> Ad-hominen attacks are unwarranted, please refrain from them. I challenge you
> to find *anything*
On Mon, 20 Apr 2020 14:07:01 -0400
Michael Orlitzky wrote:
> On 4/20/20 1:31 PM, Patrick McLean wrote:
> >> Simply having things in ::gentoo does not affect anyone who does not
> use them.
> >
>
> You keep saying that, but the fact that dev-go/* is filled with trash
> that has your name on
On 4/20/20 1:31 PM, Patrick McLean wrote:
>> Simply having things in ::gentoo does not affect anyone who does not
use them.
>
You keep saying that, but the fact that dev-go/* is filled with trash
that has your name on it prevents anyone else from doing a better job.
On Sun, 19 Apr 2020 11:37:15 -0400
Michael Orlitzky wrote:
> On 4/19/20 10:55 AM, Samuel Bernardo wrote:
> >
> > Taking into account the network sandbox requirement, sbt.eclass needs to
> > download all dependencies with some approach like EGO_SUM implementation
> > in go-module.eclass[1].
> >
Hi Michael,
On 4/19/20 9:09 PM, Michael Orlitzky wrote:
> You can do whatever you want in an overlay, but you can't introduce
> security vulnerabilities and license issues into thousands of peoples'
> homes and businesses through ::gentoo because it makes your life a tiny
> bit easier.
>
> The
On 4/19/20 3:41 PM, Samuel Bernardo wrote:
>>
>> EGO_SUM is not a legitimate approach to packaging. You have to create
>> packages for each package. I know, it sounds crazy when you say it.
>>
> I understand what you mean, but deem this dependencies as internal
> project dependencies where those
On 2020-04-19 16:37, Michael Orlitzky wrote:
> On 4/19/20 10:55 AM, Samuel Bernardo wrote:
>> Taking into account the network sandbox requirement, sbt.eclass needs to
>> download all dependencies with some approach like EGO_SUM implementation
>> in go-module.eclass[1].
>>
> EGO_SUM is not a
On Sun, Apr 19, 2020 at 8:37 AM Michael Orlitzky wrote:
> On 4/19/20 10:55 AM, Samuel Bernardo wrote:
> >
> > Taking into account the network sandbox requirement, sbt.eclass needs to
> > download all dependencies with some approach like EGO_SUM implementation
> > in go-module.eclass[1].
> >
>
>
On 4/19/20 10:55 AM, Samuel Bernardo wrote:
>
> Taking into account the network sandbox requirement, sbt.eclass needs to
> download all dependencies with some approach like EGO_SUM implementation
> in go-module.eclass[1].
>
EGO_SUM is not a legitimate approach to packaging. You have to create
Hi Benda,
Thanks for the reference to Java Packing policy since I haven't read it
before.
I also forget to mention maven build system in last email, but for now
I'm only focused on scala and sbt.
On 4/19/20 5:31 AM, Benda Xu wrote:
> That's a good idea. What's your plan to realize the
Hi Samuel,
Samuel Bernardo writes:
> My point is about other JVM languages such as scala, groovy, kotlin,
> clojure, ... And about builders such as gradle or sbt?
>
> I think that eclasses for those would be very useful to develop
> ebuilds and evolve with the right procedures.
That's a good
27 matches
Mail list logo
