Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/09/2017 05:06 PM, Michael Orlitzky wrote: > "How do we update insecure libraries?" would have been a good question > to ask *before* adding Go to the tree, because the answer is pretty > clearly "we can't." As it is now, if a go-package is to be in stable tree; the package maintainer adding a go package will need to keep track of relevant dependencies that are embedded and do a revdep of the package if a vulnerability in the chain is discovered. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 9 Mar 2017 11:06:54 -0500 Michael Orlitzkywrote: > 2. Work with the PMS team to come up with a solution for the > problem. I think dependency labels & parts fill nicely that void. I have not done proper research about it but I have yet to see a serious proposal for its inclusion though. [...] > "How do we update insecure libraries?" would have been a good question > to ask *before* adding Go to the tree, because the answer is pretty > clearly "we can't." The right way to fix it now is to create a new > class of dependencies for the CADT languages that ignore the last 40 > years of experience and statically link everything. Keep in mind that some languages do not play that well with the DSO model. Curryfication and partial function applications come to mind. Those are also part of these 40 years of experience :) Alexis.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/09/2017 10:36 AM, William Hubbs wrote: > On Wed, Mar 08, 2017 at 07:49:08PM -0500, Michael Orlitzky wrote: >> 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. > > Having things in RDEPEND that are only used at build time is also incorrect. I was not implying that you have to pick one of the two wrong solutions and implement it =) The attractive options at this point are, 1. Do nothing. 2. Work with the PMS team to come up with a solution for the problem. The other proposed solutions don't work: * Using RDEPEND is semantically incorrect, and runs afoul of the PMS because the packages don't break when their dependencies change. * Using slot operator deps in DEPEND is meaningless, and only happens to do what you want in portage when --with-bdeps is enabled. Going forward with either one of those only digs us deeper into the hole we're already in. "How do we update insecure libraries?" would have been a good question to ask *before* adding Go to the tree, because the answer is pretty clearly "we can't." The right way to fix it now is to create a new class of dependencies for the CADT languages that ignore the last 40 years of experience and statically link everything.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Wed, Mar 08, 2017 at 07:49:08PM -0500, Michael Orlitzky wrote: > 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. Having things in RDEPEND that are only used at build time is also incorrect. I'm leaning more toward the way Zac thinks about this. If package managers are not updating build-time dependencies before they build a package, this could be considered a bug. William signature.asc Description: Digital signature
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 Hubbswrote: > 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 Hubbswrote: > >> 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] 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 Hubbswrote: >> 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 Hubbswrote: > > > 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 Hubbswrote: > 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
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Tue, Mar 7, 2017 at 4:38 PM, William Hubbswrote: > 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? -- Thanks, Zac
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: > On 03/07/2017 07:02 PM, Patrick McLean wrote: > > > > You also need to recompile to get security bugs fixed. With go it's not > > just compiler options, it's also the standard library updates that need > > a recompile to get. > > > > If that's the reasoning, then don't you have the same problem with every > other library under dev-go? None of them are really needed at runtime, > but you would need to rebuild when they change to get security updates, > right? Correct, but see below. > 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. I'm sure there will be more cleanup to do if packages have go libraries in RDEPEND. William signature.asc Description: Digital signature
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/07/2017 07:02 PM, Patrick McLean wrote: > > You also need to recompile to get security bugs fixed. With go it's not > just compiler options, it's also the standard library updates that need > a recompile to get. > If that's the reasoning, then don't you have the same problem with every other library under dev-go? None of them are really needed at runtime, but you would need to rebuild when they change to get security updates, right? 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)?
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Tue, 7 Mar 2017 18:51:12 -0500 Michael Orlitzkywrote: > On 03/07/2017 05:40 PM, William Hubbs wrote: > > Hi all, > > > > I was attending SCALE, but now I'm back to answer this. > > > > On Thu, Mar 02, 2017 at 04:46:22PM -0500, Michael Orlitzky wrote: > >> What kind of dependency do we need, anyway? William, are you > >> saying that if I upgrade dev-lang/go, then things will break, but > >> if I delete dev-lang/go, everything is fine? > > > > Go programs will not *break* if you upgrade or downgrade > > dev-lang/go, but they will not get the new features or fixes in the > > new version of dev-lang/go until they are rebuilt with the new > > version. > > Ha, then I went off on a pointless tangent. > > How is this situation different from, say, a C program? You need to > recompile to get the new GCC optimizations, stack-mumbo-jumbo > protections, etc. > > You also need to recompile to get security bugs fixed. With go it's not just compiler options, it's also the standard library updates that need a recompile to get.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/07/2017 05:40 PM, William Hubbs wrote: > Hi all, > > I was attending SCALE, but now I'm back to answer this. > > On Thu, Mar 02, 2017 at 04:46:22PM -0500, Michael Orlitzky wrote: >> What kind of dependency do we need, anyway? William, are you saying that >> if I upgrade dev-lang/go, then things will break, but if I delete >> dev-lang/go, everything is fine? > > Go programs will not *break* if you upgrade or downgrade dev-lang/go, but > they will not get the new features or fixes in the new version of > dev-lang/go until they are rebuilt with the new version. Ha, then I went off on a pointless tangent. How is this situation different from, say, a C program? You need to recompile to get the new GCC optimizations, stack-mumbo-jumbo protections, etc.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
Hi all, I was attending SCALE, but now I'm back to answer this. On Thu, Mar 02, 2017 at 04:46:22PM -0500, Michael Orlitzky wrote: > What kind of dependency do we need, anyway? William, are you saying that > if I upgrade dev-lang/go, then things will break, but if I delete > dev-lang/go, everything is fine? Go programs will not *break* if you upgrade or downgrade dev-lang/go, but they will not get the new features or fixes in the new version of dev-lang/go until they are rebuilt with the new version. If you remove dev-lang/go, all Go programs on your system will run because they have everything they need from the Go libraries statically linked into them. dev-lang/go is a build time, not a runtime dependency, but dev-lang/go:= means nothing unless it is in RDEPEND. 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. William signature.asc Description: Digital signature
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 17:36:16 -0500 Michael Orlitzkywrote: > On 03/02/2017 04:53 PM, Alexis Ballier wrote: > >> > >> Back on topic: > >> > >> What kind of dependency do we need, anyway? William, are you saying > >> that if I upgrade dev-lang/go, then things will break, but if I > >> delete dev-lang/go, everything is fine? > > > > It's likely like ocaml: you link your programs ~ statically but > > everything you link needs to be built with the same compiler. So > > that'd be some kind of "build against"-RDEPEND. > > > > The tiny practical part of me thinks it's probably better to add > dev-lang/go:= to RDEPEND than it is to create an entirely new class of > dependencies to handle this. That's what I do with ocaml, it works pretty well :) My rationale is that for size-constrained installs (embedded, containers, etc.) you'd have to remove everything you don't need anyway (/usr/include, gcc, etc.) so one more or one less does not make a difference. And for normal gentoo installs, you'd want to upgrade, so better not waste your time uninstalling and reinstalling it every time. Nevertheless, build-against deps are still useful. Think of a lib #including eigen in its public headers. Is eigen a build or run depend ? It's in-between: build-against :) Alexis.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:53 PM, Alexis Ballier wrote: >> >> Back on topic: >> >> What kind of dependency do we need, anyway? William, are you saying >> that if I upgrade dev-lang/go, then things will break, but if I delete >> dev-lang/go, everything is fine? > > It's likely like ocaml: you link your programs ~ statically but > everything you link needs to be built with the same compiler. So > that'd be some kind of "build against"-RDEPEND. > The tiny practical part of me thinks it's probably better to add dev-lang/go:= to RDEPEND than it is to create an entirely new class of dependencies to handle this.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 16:46:22 -0500 Michael Orlitzkywrote: > On 03/02/2017 04:30 PM, Ciaran McCreesh wrote: > > > > The point is to specify dependencies declaratively. A dependency > > expresses a dependency, not an action. If you can't express the > > kind of dependency you need, then we need either labels or another > > *DEPEND variable to take care of it, not a bodge. > > > > In the meantime, if you give people an official bodge-maker, they'll > use it. > > Back on topic: > > What kind of dependency do we need, anyway? William, are you saying > that if I upgrade dev-lang/go, then things will break, but if I delete > dev-lang/go, everything is fine? It's likely like ocaml: you link your programs ~ statically but everything you link needs to be built with the same compiler. So that'd be some kind of "build against"-RDEPEND.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:30 PM, Ciaran McCreesh wrote: > > The point is to specify dependencies declaratively. A dependency > expresses a dependency, not an action. If you can't express the kind of > dependency you need, then we need either labels or another *DEPEND > variable to take care of it, not a bodge. > In the meantime, if you give people an official bodge-maker, they'll use it. Back on topic: What kind of dependency do we need, anyway? William, are you saying that if I upgrade dev-lang/go, then things will break, but if I delete dev-lang/go, everything is fine?
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 13:06:45 -0800 Zac Medicowrote: > On 03/02/2017 11:24 AM, Michael Orlitzky wrote: > > On 03/02/2017 02:05 PM, Zac Medico wrote: > >>> > >>> This is why we can't have nice things. > >> > >> For those that are interested, I'm planning to to make --with-bdeps > >> automatically enabled when possible: > >> > > > > > > I agree with this ^ but I don't think portage should rebuild for > > DEPEND at all. It creates one more dangerous "it works in portage!" > > situation that will plague users of other package managers. > > > > (I'm not saying it couldn't be useful, but it should go in the next > > EAPI if we're gonna do it.) > > PMS doesn't specify when rebuilds are supposed to be triggered. You > can consider the rebuilds as a means to satisfy the dependencies. > Saying that the package manager should not make an effort to satisfy > dependencies would be silly. And then have a nice ref. implementation for next EAPI. Having barely tested (*) features set in stone at each EAPI bump is even more dangerous than the "it works in portage!" situations IMHO. (*) I'm not saying features are not tested, but those that have been thrown at users for years are much more mature than the brand new ones in comparison.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 16:25:54 -0500 Michael Orlitzkywrote: > On 03/02/2017 04:06 PM, Zac Medico wrote: > >> > >> I agree with this ^ but I don't think portage should rebuild for > >> DEPEND at all. It creates one more dangerous "it works in > >> portage!" situation that will plague users of other package > >> managers. > >> > >> (I'm not saying it couldn't be useful, but it should go in the > >> next EAPI if we're gonna do it.) > > > > PMS doesn't specify when rebuilds are supposed to be triggered. You > > can consider the rebuilds as a means to satisfy the dependencies. > > Saying that the package manager should not make an effort to satisfy > > dependencies would be silly. > > It doesn't violate the PMS to do the extra rebuilds, but the PMS also > doesn't say that they should happen. > > Hypothetical situation: a developer notices that Go packages need to > be rebuilt when the compiler changes, so he adds subslot operators to > DEPEND and everything looks fine. Until someone with a different > package manager tries to use it, that is; the rebuilds aren't > triggered unless you're using portage. The point is to specify dependencies declaratively. A dependency expresses a dependency, not an action. If you can't express the kind of dependency you need, then we need either labels or another *DEPEND variable to take care of it, not a bodge. -- Ciaran McCreesh
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:06 PM, Zac Medico wrote: >> >> I agree with this ^ but I don't think portage should rebuild for DEPEND >> at all. It creates one more dangerous "it works in portage!" situation >> that will plague users of other package managers. >> >> (I'm not saying it couldn't be useful, but it should go in the next EAPI >> if we're gonna do it.) > > PMS doesn't specify when rebuilds are supposed to be triggered. You can > consider the rebuilds as a means to satisfy the dependencies. Saying > that the package manager should not make an effort to satisfy > dependencies would be silly. It doesn't violate the PMS to do the extra rebuilds, but the PMS also doesn't say that they should happen. Hypothetical situation: a developer notices that Go packages need to be rebuilt when the compiler changes, so he adds subslot operators to DEPEND and everything looks fine. Until someone with a different package manager tries to use it, that is; the rebuilds aren't triggered unless you're using portage.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 11:24 AM, Michael Orlitzky wrote: > On 03/02/2017 02:05 PM, Zac Medico wrote: >>> >>> This is why we can't have nice things. >> >> For those that are interested, I'm planning to to make --with-bdeps >> automatically enabled when possible: >> > > > I agree with this ^ but I don't think portage should rebuild for DEPEND > at all. It creates one more dangerous "it works in portage!" situation > that will plague users of other package managers. > > (I'm not saying it couldn't be useful, but it should go in the next EAPI > if we're gonna do it.) PMS doesn't specify when rebuilds are supposed to be triggered. You can consider the rebuilds as a means to satisfy the dependencies. Saying that the package manager should not make an effort to satisfy dependencies would be silly. -- Thanks, Zac
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 02:05 PM, Zac Medico wrote: >> >> This is why we can't have nice things. > > For those that are interested, I'm planning to to make --with-bdeps > automatically enabled when possible: > I agree with this ^ but I don't think portage should rebuild for DEPEND at all. It creates one more dangerous "it works in portage!" situation that will plague users of other package managers. (I'm not saying it couldn't be useful, but it should go in the next EAPI if we're gonna do it.)
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 06:47 AM, Michael Orlitzky wrote: > On 03/02/2017 09:24 AM, Mike Gilbert wrote: >>> >>> In other words, the ":=" only does something special in RDEPEND. That >>> makes sense when you think of it as meaning "the thing will break" >>> rather than "I want to do a rebuild." The only reason it's not an error >>> to put them in DEPEND is because it would annoy everyone doing >>> DEPEND="${RDEPEND}". >> >> Portage has interesting behavior for ":=" in DEPEND: it varies >> depending on your "with-bdeps" setting. >> > > This is why we can't have nice things. For those that are interested, I'm planning to to make --with-bdeps automatically enabled when possible: https://bugs.gentoo.org/show_bug.cgi?id=598444#c4 I hope to implement this very soon, to be included in the next portage release. -- Thanks, Zac
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 14:56:37 + Ciaran McCreeshwrote: > On Thu, 2 Mar 2017 09:47:35 -0500 > Michael Orlitzky wrote: > > On 03/02/2017 09:24 AM, Mike Gilbert wrote: > > >> > > >> In other words, the ":=" only does something special in RDEPEND. > > >> That makes sense when you think of it as meaning "the thing will > > >> break" rather than "I want to do a rebuild." The only reason it's > > >> not an error to put them in DEPEND is because it would annoy > > >> everyone doing DEPEND="${RDEPEND}". > > > > > > Portage has interesting behavior for ":=" in DEPEND: it varies > > > depending on your "with-bdeps" setting. > > > > > > > This is why we can't have nice things. > > Actually you can't have nice things because the labels proposal was > voted down for "being invented by the wrong people". Don't get too much into conspiracy theories, I think it has been dismissed because it would require rewriting every dependency and there has not been any portage implementation afaik. Instead of that, people seem to prefer having [A-Z]DEPEND :)
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 09:47:35 -0500 Michael Orlitzkywrote: > On 03/02/2017 09:24 AM, Mike Gilbert wrote: > >> > >> In other words, the ":=" only does something special in RDEPEND. > >> That makes sense when you think of it as meaning "the thing will > >> break" rather than "I want to do a rebuild." The only reason it's > >> not an error to put them in DEPEND is because it would annoy > >> everyone doing DEPEND="${RDEPEND}". > > > > Portage has interesting behavior for ":=" in DEPEND: it varies > > depending on your "with-bdeps" setting. > > > > This is why we can't have nice things. Actually you can't have nice things because the labels proposal was voted down for "being invented by the wrong people". -- Ciaran McCreesh
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 09:24 AM, Mike Gilbert wrote: >> >> In other words, the ":=" only does something special in RDEPEND. That >> makes sense when you think of it as meaning "the thing will break" >> rather than "I want to do a rebuild." The only reason it's not an error >> to put them in DEPEND is because it would annoy everyone doing >> DEPEND="${RDEPEND}". > > Portage has interesting behavior for ":=" in DEPEND: it varies > depending on your "with-bdeps" setting. > This is why we can't have nice things. From recruiting-simplifies+bncbczi37v74ejrbhpb4dcqkgqevmgh...@googlegroups.com Thu Mar 02 06:48:21 2017 Return-path:Envelope-to: arch...@mail-archive.com Delivery-date: Thu, 02 Mar 2017 06:48:21 -0800 Received: from c7-b.mxthunder.net ([208.53.48.218]) by mail-archive.com with esmtp (Exim 4.76) (envelope-from ) id 1cjS1l-0004Mw-J8 for arch...@mail-archive.com; Thu, 02 Mar 2017 06:48:21 -0800 Received: by bolt10b.mxthunder.net (Postfix, from userid 12345) id 3vYwCz12fsz1x6S9; Thu, 2 Mar 2017 06:48:03 -0800 (PST) Received: from mail-ot0-f185.google.com (mail-ot0-f185.google.com [74.125.82.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bolt10b.mxthunder.net (Postfix) with ESMTPS id 3vYwCf50k0z1w6cq for ; Thu, 2 Mar 2017 06:47:58 -0800 (PST) Received: by mail-ot0-f185.google.com with SMTP id i1sf42597331ota.0 for ; Thu, 02 Mar 2017 06:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:message-id:date:subject:from:reply-to:mime-version :content-transfer-encoding:feedback-id:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-unsubscribe; bh=uzvc0Q02asumLIIfovb8DCn3aEcZPE52kTwHSzf5HgM=; b=LrohXxoiE/IS0VIzh1kiidCKSdQH5/ltxfaHDjfnhj4OhpTGSKnDWLhijp0zYieErP G8efzJZBbR3q+i4ynrbGGlGLdtrZlau3ePYfHFWt3B7i3xwvdgO5g6rPHfKxkieWJyyc CptEmLEUxscTmpc2zMVBjZcXBTqGDh7aBYbzFjbtiKq4563dl5LIpNGMOdjmgvu1DagE vgxCngrAdowlAwm+clMHsvnqzsMfWeS3UF3NCZ1y+F1CU8zvLZtel4utqT4caEcn7f73 x0WZPUSce/4GF+/TlPsLVhpNg29e45c90g8i3do9FcLOg0u9qKdOLV8m6sWY158yMWob iipQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:message-id:date:subject:from:reply-to :mime-version:content-transfer-encoding:feedback-id :x-original-sender:x-original-authentication-results:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-unsubscribe; bh=uzvc0Q02asumLIIfovb8DCn3aEcZPE52kTwHSzf5HgM=; b=CRGSKoKvisS5r6a3Tg9AdzSi8JuvUrH3YO/iQgxigotVNGwU1ka9OB6qQCBmrPFTZ6 +wRaFulb/NI8c+qDIqxq2YGHFeuHSEgqnAsH1F06UEXUwZZdZFdhqQHdy3qvRNbiVFsr dD7IDZW3xVJVeUs65oFGUBXgPGht8a4rWtYzlLQ1vLbWJXKQ6DxsxmHVpML5vtPgsns2 t9L7zhIqvV+oBr/kZByZLjMbIkp+H/M01Hu/bDBiX0qwcQVFpStTx6+7cUSApUZXUsPF mv+pLBhVVJ+iy0eBoT6ze3AoEdHFnFvbAUKBs296ZTEu5JWgF35sXyNHuENqcQKf4E9u PfAQ== Sender: recruiting-simplif...@googlegroups.com X-Gm-Message-State: AMke39mzTJPQ8HlkO4TvxDIFEaJE+EM/G5GdlrBEcI7wFP06h/n3Bp0NheTOHKJYnyaJqQ== X-Received: by 10.36.25.140 with SMTP id b134mr749103itb.6.1488466078157; Thu, 02 Mar 2017 06:47:58 -0800 (PST) X-BeenThere: recruiting-simplif...@googlegroups.com Received: by 10.107.134.99 with SMTP id i96ls2076467iod.1.gmail; Thu, 02 Mar 2017 06:47:57 -0800 (PST) X-Received: by 10.107.47.2 with SMTP id j2mr2693169ioo.74.1488466077742; Thu, 02 Mar 2017 06:47:57 -0800 (PST) Received: from a10-127.smtp-out.amazonses.com (a10-127.smtp-out.amazonses.com. [54.240.10.127]) by gmr-mx.google.com with ESMTPS id r6si907363ywb.6.2017.03.02.06.47.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Mar 2017 06:47:57 -0800 (PST) Received-SPF: pass (google.com: domain of 0100015a8f7de508-59f183c1-021f-4d2c-bcff-9b4935b43c6d-000...@amazonses.com designates 54.240.10.127 as permitted sender) client-ip=54.240.10.127; Message-ID: <0100015a8f7de508-59f183c1-021f-4d2c-bcff-9b4935b43c6d-000...@email.amazonses.com> Date: Thu, 2 Mar 2017 14:47:56 + Subject: Recruiting-Simplifies Required: UX Designer with Java Script, Wireframe experience at Ann Arbor, Michigan - Contract From: Vamsheedhar Reply-To: vams...@svktechinc.com MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SES-Outgoing: 2017.03.02-54.240.10.127 Feedback-ID:
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, Mar 2, 2017 at 9:03 AM, Michael Orlitzkywrote: > On 03/02/2017 04:58 AM, Alexis Ballier wrote: >> >> Is it really abusing ? >> := deps in DEPEND only would also make sense for e.g. code generators >> > > Slot operator dependencies are ignored in DEPEND: > > Indicates that any slot value is acceptable. In addition, for runtime > dependencies, indicates that the package will break unless a matching > package with slot and sub-slot equal to the slot and sub-slot of the > best installed version at the time the package was built is available. > > In other words, the ":=" only does something special in RDEPEND. That > makes sense when you think of it as meaning "the thing will break" > rather than "I want to do a rebuild." The only reason it's not an error > to put them in DEPEND is because it would annoy everyone doing > DEPEND="${RDEPEND}". Portage has interesting behavior for ":=" in DEPEND: it varies depending on your "with-bdeps" setting. floppym@naomi ~ % emerge -uDpv --with-bdeps=n @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-lang/go-1.8:0/1.8::gentoo [1.7.5:0/1.7.5::gentoo] USE="-gccgo" 0 KiB Total: 1 package (1 upgrade), Size of downloads: 0 KiB floppym@naomi ~ % emerge -uDpv --with-bdeps=y @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild r U ] dev-lang/go-1.8:0/1.8::gentoo [1.7.5:0/1.7.5::gentoo] USE="-gccgo" 0 KiB [ebuild rR] app-admin/cli53-0.8.7::gentoo 0 KiB Total: 2 packages (1 upgrade, 1 reinstall), Size of downloads: 0 KiB The following packages are causing rebuilds: (dev-lang/go-1.8:0/1.8::gentoo, ebuild scheduled for merge) causes rebuilds for: (app-admin/cli53-0.8.7:0/0::gentoo, ebuild scheduled for merge)
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:58 AM, Alexis Ballier wrote: > > Is it really abusing ? > := deps in DEPEND only would also make sense for e.g. code generators > Slot operator dependencies are ignored in DEPEND: Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with slot and sub-slot equal to the slot and sub-slot of the best installed version at the time the package was built is available. In other words, the ":=" only does something special in RDEPEND. That makes sense when you think of it as meaning "the thing will break" rather than "I want to do a rebuild." The only reason it's not an error to put them in DEPEND is because it would annoy everyone doing DEPEND="${RDEPEND}".
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Wed, 1 Mar 2017 18:18:01 -0600 William Hubbswrote: > To avoid abusing slot dependencies for dev-lang/go since it is not > needed at runtime I need to do the following. Is it really abusing ? := deps in DEPEND only would also make sense for e.g. code generators
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Wed, Mar 1, 2017 at 7:18 PM, William Hubbswrote: > All, > > the dependencies for dev-lang/go need to force a rebuild every time the > compiler is downgraded or upgraded. This already happens for me. It is working as expected. > To avoid abusing slot dependencies for dev-lang/go since it is not > needed at runtime I need to do the following. > > I need to introduce virtual/go-1.7.5, virtual/go-1.8 and > virtual/go-. The attachment shows 1.8 but it is the same for all > versions. > > Also, the attached patch needs to be applied to golang-base.eclass. > > This is based on the following wiki page: > > Ahttps://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots#Using_virtuals_to_expose_multiple_ABIs > > Any thoughts? I don't see how introducing a layer of indirection solves any problem here.
[gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
All, the dependencies for dev-lang/go need to force a rebuild every time the compiler is downgraded or upgraded. To avoid abusing slot dependencies for dev-lang/go since it is not needed at runtime I need to do the following. I need to introduce virtual/go-1.7.5, virtual/go-1.8 and virtual/go-. The attachment shows 1.8 but it is the same for all versions. Also, the attached patch needs to be applied to golang-base.eclass. This is based on the following wiki page: Ahttps://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots#Using_virtuals_to_expose_multiple_ABIs Any thoughts? William # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 EAPI=6 DESCRIPTION="virtual for the Go compiler" SLOT="0/${PV}" KEYWORDS="-* ~amd64 ~arm ~arm64 ~ppc64 ~x86 ~amd64-fbsd ~x86-fbsd ~x64-macos ~x64-solaris" DEPEND="~dev-lang/go-${PV}" diff --git a/eclass/golang-base.eclass b/eclass/golang-base.eclass index 0cfd07e..e841763 100644 --- a/eclass/golang-base.eclass +++ b/eclass/golang-base.eclass @@ -22,7 +22,8 @@ if [[ -z ${_GOLANG_BASE} ]]; then _GOLANG_BASE=1 -DEPEND=">=dev-lang/go-1.7:=" +DEPEND=">=virtual/go-1.7" +RDEPEND=">=virtual/go-1.7:=" # Do not complain about CFLAGS etc since go projects do not use them. QA_FLAGS_IGNORED='.*' signature.asc Description: Digital signature