On Fri, 13 Sep 2019 12:50:48 -0400
Michael Orlitzky wrote:
> The rule "don't copy and paste code" applies to your
> linker just as much as it applies to the first program you wrote in
> CS101, and for the same reasons.
My experience has taught me to ignore the rule as written, and consider
it m
On Fri, 13 Sep 2019 19:44:55 -0400
Michael Orlitzky wrote:
> They silently get something less than
> they're expecting. We would be better off telling people to run "go
> whatever" themselves, or by putting this stuff in an overlay where
> expectations are clearly defined.
That suggestion actua
On 9/14/19 1:06 PM, Alec Warner wrote:
>
> - There appears to be some expectation that consensus is required on
> the ML; this has (IMHO) never been true. The 'decider' for what to do
> isn't the mailing list (by GLEP, it's the council). So this idea that
> you can object on the ML and stop a thi
On Fri, Sep 13, 2019 at 4:45 PM Michael Orlitzky wrote:
> (Replying to both messages at once.)
>
>
> On 9/13/19 4:17 PM, Patrick McLean wrote:
> >>
> > I don't think anyone here has suggested that any go packages are
> > installed in the stage3 tarballs, or included in profiles. Something's
> > p
> On Fri, 13 Sep 2019, Patrick McLean wrote:
> Something's presence in the tree does not mean that you are required
> to install it. A package's presence in the tree really has little to
> zero effect on any user that does not use the package.
I wonder if that's always true. Distros adopting
On Fri, 13 Sep 2019 19:44:55 -0400
Michael Orlitzky wrote:
> (Replying to both messages at once.)
>
>
> On 9/13/19 4:17 PM, Patrick McLean wrote:
> >>
> > I don't think anyone here has suggested that any go packages are
> > installed in the stage3 tarballs, or included in profiles.
> > Someth
(Replying to both messages at once.)
On 9/13/19 4:17 PM, Patrick McLean wrote:
>>
> I don't think anyone here has suggested that any go packages are
> installed in the stage3 tarballs, or included in profiles. Something's
> presence in the tree does not mean that you are required to install it.
>
On Fri, 13 Sep 2019 12:50:48 -0400
Michael Orlitzky wrote:
> On 9/12/19 1:45 PM, Alec Warner wrote:
> >
> > Er, I'm fairly sure computer *science* has not conclusively proven
> > that dynamic binaries are somehow superior to static binaries.
> >
>
>
> If you statically link to a library, th
On Fri, 13 Sep 2019 08:29:20 -0400
Michael Orlitzky wrote:
> On 9/13/19 5:19 AM, Kent Fredric wrote:
> > On Thu, 12 Sep 2019 17:58:08 -0400
> > Michael Orlitzky wrote:
> >
> >> What kind of math would convince you that an idea with all "cons"
> >> and no "pros" is bad?
> >
> > Is "upstream
On 9/12/19 1:45 PM, Alec Warner wrote:
>
> Er, I'm fairly sure computer *science* has not conclusively proven that
> dynamic binaries are somehow superior to static binaries.
>
Please don't make me work this hard ever again.
The principal of modularity in software design goes back to at least
1
On 9/13/19 5:19 AM, Kent Fredric wrote:
> On Thu, 12 Sep 2019 17:58:08 -0400
> Michael Orlitzky wrote:
>
>> What kind of math would convince you that an idea with all "cons" and no
>> "pros" is bad?
>
> Is "upstream tooling doesn't work without static compilation" or
> "built packages tend to ne
On 9/12/19 11:13 PM, Mike Gilbert wrote:
>
> I'm really objecting to your suggestion that we abuse an existing
> Portage/PMS feature to do something beyond its design. Adding
> fictitious runtime dependencies is wrong, and seems like a very lazy
> solution.
Ok, you're right.
> If you want to pr
On Thu, 12 Sep 2019 17:58:08 -0400
Michael Orlitzky wrote:
> What kind of math would convince you that an idea with all "cons" and no
> "pros" is bad?
Is "upstream tooling doesn't work without static compilation" or
"built packages tend to need exact version matching at runtime to work"
( which
On Thu, Sep 12, 2019 at 8:14 PM Michael Orlitzky wrote:
>
> On 9/12/19 5:23 PM, Mike Gilbert wrote:
> >
> > Putting the dependencies in RDEPEND means users get stuck with yet
> > another copy of the code installed, in addition to the copy that is
> > statically linked into all reverse dependencies
On Thu, Sep 12, 2019 at 6:56 PM Alec Warner wrote:
>
>
> On Thu, Sep 12, 2019 at 5:14 PM Michael Orlitzky wrote:
>
>> On 9/12/19 5:23 PM, Mike Gilbert wrote:
>> >
>> > Putting the dependencies in RDEPEND means users get stuck with yet
>> > another copy of the code installed, in addition to the c
On Thu, Sep 12, 2019 at 5:14 PM Michael Orlitzky wrote:
> On 9/12/19 5:23 PM, Mike Gilbert wrote:
> >
> > Putting the dependencies in RDEPEND means users get stuck with yet
> > another copy of the code installed, in addition to the copy that is
> > statically linked into all reverse dependencies.
On 9/12/19 5:23 PM, Mike Gilbert wrote:
>
> Putting the dependencies in RDEPEND means users get stuck with yet
> another copy of the code installed, in addition to the copy that is
> statically linked into all reverse dependencies.
>
> It's not a very good solution to the problem.
>
No argument
On 9/12/19 1:45 PM, Alec Warner wrote:
>
> Er, I'm fairly sure computer *science* has not conclusively proven that
> dynamic binaries are somehow superior to static binaries.
>
What are the benefits of static linking to the end user on Gentoo? The
comprehensive list is usually,
* The applicat
On Thu, Sep 12, 2019 at 5:11 PM Michael Orlitzky wrote:
>
> On 9/12/19 1:43 PM, Mike Gilbert wrote:
> >
> > They do "go away" if you pass the right options to emerge, or if you
> > install it from a binpkg in the first place.
> >
>
> The dependencies are statically linked into the final executable
On 9/12/19 1:43 PM, Mike Gilbert wrote:
>
> They do "go away" if you pass the right options to emerge, or if you
> install it from a binpkg in the first place.
>
The dependencies are statically linked into the final executable forever
and receive no security updates. Portage doesn't even know th
On Thu, 12 Sep 2019 12:52:31 -0400
Michael Orlitzky wrote:
> Subslots do this already. Portage does this already. We have this "tool
> that people would want," but only if developers can be bothered to
> package things.
For some things (go, rust), using dynamic linking for all dependencies,
and
On Thu, Sep 12, 2019 at 9:52 AM Michael Orlitzky wrote:
> On 9/12/19 12:42 PM, Alec Warner wrote:
> >
> > In general I don't see bundling as a major problem. In the land of
> > dynamic binaries, it's a big advantage because you can upgrade libfoo
> > and all consumers of libfoo get the upgrade up
On Thu, Sep 12, 2019 at 1:05 PM Michael Orlitzky wrote:
>
> On 9/12/19 12:55 PM, Mike Gilbert wrote:
> >
> > Portage only handles rebuilds for slot-operator deps in RDEPEND. It
> > ignores slot-operators in DEPEND.
> >
>
> Sure, but putting them in RDEPEND isn't a problem. It's not like the
> stat
On Thu, 2019-09-12 at 09:42 -0700, Alec Warner wrote:
> On Thu, Sep 12, 2019 at 9:14 AM Michael Orlitzky wrote:
>
> > On 9/12/19 11:46 AM, William Hubbs wrote:
> > > In other words, the way I see this is a tree-wide issue. LICENSE= for
> > > any package should list every license for every package
On 9/12/19 12:55 PM, Mike Gilbert wrote:
>
> Portage only handles rebuilds for slot-operator deps in RDEPEND. It
> ignores slot-operators in DEPEND.
>
Sure, but putting them in RDEPEND isn't a problem. It's not like the
statically-linked bundled dependencies actually go away with a depclean,
any
On Thu, Sep 12, 2019 at 12:52 PM Michael Orlitzky wrote:
>
> On 9/12/19 12:42 PM, Alec Warner wrote:
> >
> > In general I don't see bundling as a major problem. In the land of
> > dynamic binaries, it's a big advantage because you can upgrade libfoo
> > and all consumers of libfoo get the upgrade
On 9/12/19 12:42 PM, Alec Warner wrote:
>
> In general I don't see bundling as a major problem. In the land of
> dynamic binaries, it's a big advantage because you can upgrade libfoo
> and all consumers of libfoo get the upgrade upon process restart. This
> isn't true for most go programs which ar
On Thu, Sep 12, 2019 at 8:46 AM William Hubbs wrote:
> On Wed, Sep 11, 2019 at 05:05:50PM -0700, Alec Warner wrote:
> > On Wed, Sep 11, 2019 at 4:48 PM William Hubbs
> wrote:
> >
> > > On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote:
> > > > On Wed, Sep 11, 2019 at 10:39 AM Michael O
On Thu, Sep 12, 2019 at 9:14 AM Michael Orlitzky wrote:
> On 9/12/19 11:46 AM, William Hubbs wrote:
> >
> > In other words, the way I see this is a tree-wide issue. LICENSE= for
> > any package should list every license for every package it links to or
> > uses.
> >
> There is no issue tree-wide,
On 9/12/19 11:46 AM, William Hubbs wrote:
>
> In other words, the way I see this is a tree-wide issue. LICENSE= for
> any package should list every license for every package it links to or
> uses.
>
There is no issue tree-wide, because no one else is trying to cut
corners and bundle every dependen
On Wed, Sep 11, 2019 at 05:05:50PM -0700, Alec Warner wrote:
> On Wed, Sep 11, 2019 at 4:48 PM William Hubbs wrote:
>
> > On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote:
> > > On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky
> > wrote:
> > >
> > > > On 9/11/19 1:21 PM, William Hubb
On Wed, Sep 11, 2019 at 4:48 PM William Hubbs wrote:
> On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote:
> > On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky
> wrote:
> >
> > > On 9/11/19 1:21 PM, William Hubbs wrote:
> > > > +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> > > > ...
> > > >
>
On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote:
> On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky wrote:
>
> > On 9/11/19 1:21 PM, William Hubbs wrote:
> > > +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> > > ...
> > >
> > > LICENSE="MIT"
> >
> > This license is wrong, as it's pretty much g
On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky wrote:
> On 9/11/19 1:21 PM, William Hubbs wrote:
> > +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> > ...
> >
> > LICENSE="MIT"
>
> This license is wrong, as it's pretty much guaranteed to be every time
> you commit one of these packages. I find it pretty
On Thu, Sep 12, 2019 at 07:15:28AM +1200, Kent Fredric wrote:
> On Wed, 11 Sep 2019 12:47:20 -0500
> William Hubbs wrote:
>
> > Sorry, That train already left the station with the golang-* eclasses
> > and there is nothing we can do about it.
>
> Saying "this creates a legal problem" followed by
On Wed, 11 Sep 2019 12:47:20 -0500
William Hubbs wrote:
> Sorry, That train already left the station with the golang-* eclasses
> and there is nothing we can do about it.
Saying "this creates a legal problem" followed by "eh, nothing we can
do about it, carry on" really doesn't work in reality,
On 9/11/19 1:47 PM, William Hubbs wrote:
> On Wed, Sep 11, 2019 at 01:39:32PM -0400, Michael Orlitzky wrote:
>> On 9/11/19 1:21 PM, William Hubbs wrote:
>>> +++ b/dev-vcs/hub/hub-2.12.3.ebuild
>>> ...
>>>
>>> LICENSE="MIT"
>>
>> This license is wrong, as it's pretty much guaranteed to be every ti
On Wed, Sep 11, 2019 at 01:39:32PM -0400, Michael Orlitzky wrote:
> On 9/11/19 1:21 PM, William Hubbs wrote:
> > +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> > ...
> >
> > LICENSE="MIT"
>
> This license is wrong, as it's pretty much guaranteed to be every time
> you commit one of these packages. I find
On 9/11/19 1:21 PM, William Hubbs wrote:
> +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> ...
>
> LICENSE="MIT"
This license is wrong, as it's pretty much guaranteed to be every time
you commit one of these packages. I find it pretty troubling that one
corporation is able to force this stuff through even
39 matches
Mail list logo
