Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/08/2017 02:20 PM, William Hubbs wrote: > > Another option is to not force this and rely on everyone to use > --with-bdeps=y to make the rebuild happen. > That feature is portage-only. Slot operator deps in DEPEND are meaningless.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Wed, Mar 8, 2017 at 11:20 AM, William Hubbs wrote: > On Wed, Mar 08, 2017 at 07:44:01AM -0500, Michael Orlitzky wrote: >> On 03/08/2017 01:27 AM, Zac Medico wrote: >> > On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs wrote: >> >> On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: >> >>> If all dev-go libraries wind up in RDEPEND solely to force rebuilds on >> >>> upgrades, why not do the same with the standard library (dev-lang/go)? >> >> >> >> They should not end up in rdepend at all since we only need them at >> >> build-time. >> > >> > Shouldn't we get rebuilds when the dev-go libraries are upgraded too? >> > >> >> That's what I was getting at. >> >> Another reading of the PMS reminds me (as Kent pointed out) that >> slot-operator deps shouldn't be used for would-be-nice stuff. It says >> specifically that := "indicates that the package will break..." > > Another option is to not force thisand rely on everyone to use > --with-bdeps=y to make the rebuild happen. > > I'm not sure whether this is a good idea, but it makes sense in a way > since we are talking about build-time dependencies. We just merged a portage patch the enables --with-bdeps automatically when --usepkg is not enabled: https://bugs.gentoo.org/show_bug.cgi?id=598444 -- Thanks, Zac
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Wed, Mar 08, 2017 at 07:44:01AM -0500, Michael Orlitzky wrote: > On 03/08/2017 01:27 AM, Zac Medico wrote: > > On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs wrote: > >> On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: > >>> If all dev-go libraries wind up in RDEPEND solely to force rebuilds on > >>> upgrades, why not do the same with the standard library (dev-lang/go)? > >> > >> They should not end up in rdepend at all since we only need them at > >> build-time. > > > > Shouldn't we get rebuilds when the dev-go libraries are upgraded too? > > > > That's what I was getting at. > > Another reading of the PMS reminds me (as Kent pointed out) that > slot-operator deps shouldn't be used for would-be-nice stuff. It says > specifically that := "indicates that the package will break..." Another option is to not force thisand rely on everyone to use --with-bdeps=y to make the rebuild happen. I'm not sure whether this is a good idea, but it makes sense in a way since we are talking about build-time dependencies. William signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
> I don't have time nor the familiarity to properly maintain bitcoins > myself. Every time Luke wants to make a change, I get nothing but > negative advice - what not to do, but not what to do. If there were an > unpopular package I would just drop it to maintainer-needed. But do we > really want a distro that doesn't provide bitcoins? > I suspect that it is because every time Luke wants to make a change, he wants to push his patchset as default enabled on Gentoo while nobody seems to be interested in this. I will ignore all negative advice regarding this package unless it is > balanced with positive advice. Please point out what lines of the patch > should be changed and what they should be changed to, else I will commit > the patch as provided. > Simple, do the rename by all means but don't enable it by default. Mathy
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
On 3/7/17 12:18 PM, Peter Stuge wrote: > Anthony G. Basile wrote: >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch >> against the bitcoin eclass. The following is his proposed change. >> I'll commit it after review. > > Please do not do that, Anthony. > I don't have time nor the familiarity to properly maintain bitcoins myself. Every time Luke wants to make a change, I get nothing but negative advice - what not to do, but not what to do. If there were an unpopular package I would just drop it to maintainer-needed. But do we really want a distro that doesn't provide bitcoins? I will ignore all negative advice regarding this package unless it is balanced with positive advice. Please point out what lines of the patch should be changed and what they should be changed to, else I will commit the patch as provided. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/08/2017 01:27 AM, Zac Medico wrote: > On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs wrote: >> On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: >>> If all dev-go libraries wind up in RDEPEND solely to force rebuilds on >>> upgrades, why not do the same with the standard library (dev-lang/go)? >> >> They should not end up in rdepend at all since we only need them at >> build-time. > > Shouldn't we get rebuilds when the dev-go libraries are upgraded too? > That's what I was getting at. Another reading of the PMS reminds me (as Kent pointed out) that slot-operator deps shouldn't be used for would-be-nice stuff. It says specifically that := "indicates that the package will break..."
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
W dniu 08.03.2017, śro o godzinie 21∶07 +1300, użytkownik Kent Fredric napisał: > On Tue, 7 Mar 2017 16:40:06 -0600 > William Hubbs wrote: > > > What I need is a way to force all go programs on your system to rebuild > > when the version of dev-lang/go on your system changes, and this method > > with virtuals is the only way I can think of to make that happen and > > allow you to remove dev-lang/go. > > Given the strength of := binding, I'd discourage against this. > > Causing portage resolver catastrophes to solve a "it would be nice if ..." > problem > is a bad trade-off. > > := Should be restricted to things that it is *necessary* for. > > What I think is needed is a weaker version of := which is advisory: that is, > portage > ignores the binding in entirety unless portage options dictate "rebuild > things even if > strictly not necessary" > > And this levity should mean portage should be more amenable to break graphs > to make install possible. ( Whereas with := , the presence of such a spec > causes portage > to have tantrums when the underlying dependency changes ) ...which boils down to people having no clue what := actually means and not caring to learn that before proposing awesome solutions. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Tue, 7 Mar 2017 16:40:06 -0600 William Hubbs wrote: > What I need is a way to force all go programs on your system to rebuild > when the version of dev-lang/go on your system changes, and this method > with virtuals is the only way I can think of to make that happen and > allow you to remove dev-lang/go. Given the strength of := binding, I'd discourage against this. Causing portage resolver catastrophes to solve a "it would be nice if ..." problem is a bad trade-off. := Should be restricted to things that it is *necessary* for. What I think is needed is a weaker version of := which is advisory: that is, portage ignores the binding in entirety unless portage options dictate "rebuild things even if strictly not necessary" And this levity should mean portage should be more amenable to break graphs to make install possible. ( Whereas with := , the presence of such a spec causes portage to have tantrums when the underlying dependency changes ) pgpVt13D9Nto2.pgp Description: OpenPGP digital signature
