Re: [gentoo-dev] NPM / NodeJS project
On Sun, 28 Jun 2015 12:30:25 -0400 Michael Orlitzky m...@gentoo.org wrote: I recently found a need for the CoffeeScript compiler[0] that runs on top of NodeJS. Its test suite requires a bunch of other javascript packages, and I wound up packaging enough of them to test CoffeeScript. In the process I wrote an eclass to handle packages hosted on the npm registry[1] and install them globally. I put all of this in an overlay for now: https://github.com/orlitzky/npm We don't have any standalone javascript packages in the tree at the moment but I know there's been some interest before. Is anyone still (planning on) working on javascript stuff in-tree? If not, I'll probably commit dev-lang/coffee-script to the tree without its test suite. But if so, the eclass and few dev-js packages I have might be a good start. Then I could add coffee-script with its test suite working. [0] http://coffeescript.org/ [1] https://www.npmjs.com/ Is this what I prompted about a year or more ago, and drew no interest in pursuing the npm path? I cited an eclass called npm.eclass in a dev's overlay. The conclusion was that using npm to install anything competed with portage at a level that made it a 'no go'. This came from members of the portage 'team'. It is a very awkward topic. -- kind regards Ian Delaney
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On Tue, Jun 30, 2015 at 04:48:29PM -0700, Zac Medico wrote: On 06/30/2015 03:08 PM, William Hubbs wrote: Thinking about this, there may be a third option. This would take a slight reworking of the golang-build.eclass, but that is easy to do, and it would possibly remove the subslot from the dependencies. The source code is where the compatibility between versions of Go is, not the static objects, so what if, for third-party go packages, we skip installing the static objects? If we did this with consul, for example, then the source code for all those libraries (that have no other consumers) would have to be installed in order to build consul-template against the consul's api library. It would be similar to a header dependency. This would necessitate the introduction of build-against dependencies [1], or equivalent virtuals (like virtual/podofo-build). How is this different from DEPEND=dev-go/podofo for example or DEPEND==dev-go/fodofo-0_pre? The only down side of this would be that there might be longer rebuilds if the packages have multiple consumers, but it gets rid of the static objects. What do you think? Considering the similarity to header dependencies, I don't know. The subslot thing seems slightly more appealing to me. I got the idea of not installing the objects from Debian's description of how they do this [1]; they do not mention installing the objects. Let me know what you think. William [1] http://pkg-go.alioth.debian.org/packaging.html signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 07:01 PM, William Hubbs wrote: On Tue, Jun 30, 2015 at 04:48:29PM -0700, Zac Medico wrote: On 06/30/2015 03:08 PM, William Hubbs wrote: Thinking about this, there may be a third option. This would take a slight reworking of the golang-build.eclass, but that is easy to do, and it would possibly remove the subslot from the dependencies. The source code is where the compatibility between versions of Go is, not the static objects, so what if, for third-party go packages, we skip installing the static objects? If we did this with consul, for example, then the source code for all those libraries (that have no other consumers) would have to be installed in order to build consul-template against the consul's api library. It would be similar to a header dependency. This would necessitate the introduction of build-against dependencies [1], or equivalent virtuals (like virtual/podofo-build). How is this different from DEPEND=dev-go/podofo for example or DEPEND==dev-go/fodofo-0_pre? The virtual/podofo-build package pulls in dev-libs/boost, since packages which build against podofo will fail to build unless the boost headers are installed. Since dev-libs/boost is not a run-time dependency of podofo, and it's not a direct build-time dependency of packages that build against podofo, we pull it in via virtual/podofo-build. If we install Go source files without the corresponding static libraries, they we create a similar situation to the above. For example, if consul doesn't install its static api library, then anything that wants to build against that library is going to need indirect dependencies installed in order to build that library. The indirect dependencies are not needed if there is an installed instance of consul's static api library. The only down side of this would be that there might be longer rebuilds if the packages have multiple consumers, but it gets rid of the static objects. What do you think? Considering the similarity to header dependencies, I don't know. The subslot thing seems slightly more appealing to me. I got the idea of not installing the objects from Debian's description of how they do this [1]; they do not mention installing the objects. Let me know what you think. William [1] http://pkg-go.alioth.debian.org/packaging.html As I understand it, debian does the equivalent of putting the Go dependencies in both DEPEND and RDEPEND. This means that users are forced to keep build-time dependencies around after they are no longer needed. -- Thanks, Zac
Re: [gentoo-dev] NPM / NodeJS project
On 06/30/2015 03:56 AM, Ian Delaney wrote: Is this what I prompted about a year or more ago, and drew no interest in pursuing the npm path? I cited an eclass called npm.eclass in a dev's overlay. The conclusion was that using npm to install anything competed with portage at a level that made it a 'no go'. This came from members of the portage 'team'. It is a very awkward topic. No, but we may have wound up with a similar idea. I only became interested last week when somebody gave me a coffeescript program to deploy at work and there was no coffeescript. My eclass isn't using npm to do the actual install, since npm won't do a global install. I am using it as a lazy way to run the test suite (npm test), and I'm defaulting to npmjs.org as HOMEPAGE/SRC_URI because they have nice predictable URLs. But the src_install manually copies the javascript bits to a location where node can find them.
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/29/2015 11:25 PM, Zac Medico wrote: Considering that Go binaries are statically linked, you'll end up with a bunch of Go libraries installed that you don't need during run-time. They'll eventually give this up, because everyone does when their language starts seeing serious use. I won't pretend that's a real argument though. Suppose ten years from now everything is written in Go. I have 500 statically linked Go packages on my system, all of whose dependencies were built and compiled-in at install time. Now someone finds a remote root vulnerability in the go-openssl library. I know some of the packages I have installed were built against it. What do I do? At least with the useless dev-go/go-openssl installed, I can use subslots to rebuild everything after an upgrade to the fixed version.
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
All, we have digressed a bit, so I want to bring the discussion back to what my main concerns are about this issue. 1. Should we bundle Go packages with Go software? If we do, except for the Go standard library which is part of dev-lang/go, do we need to bother with installing Go sources and packages at all? The down side of the whole bundling idea is that every consumer on someone's system could potentially have a different version of the Go package, which doesn't lend itself well to security concerns. This is why bundling is generally discouraged in Gentoo. Also, if we bundle, most of dev-go/* doesn't need to exist because these libraries would be bundled into and statically linked into the software that needs them. 2. How should we bundle? This is where my concern about consul and some other ebuilds comes in. The way the consul ebuild is written (putting the commit hashes of dependencies in SRC_URI) assumes that all of the dependencies will stay on github. This makes the ebuild far less flexable than go itself is. If we are going to bundle, I would rather have one tarball that includes all of the sources for consul and the dependent libraries dropped on the Gentoo mirrors. Such a tarball is very easy to create. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 08:49 AM, Michael Orlitzky wrote: On 06/29/2015 11:25 PM, Zac Medico wrote: Considering that Go binaries are statically linked, you'll end up with a bunch of Go libraries installed that you don't need during run-time. They'll eventually give this up, because everyone does when their language starts seeing serious use. I won't pretend that's a real argument though. Yeah, we'll see. We need to deal with the current version of reality though... Suppose ten years from now everything is written in Go. I have 500 statically linked Go packages on my system, all of whose dependencies were built and compiled-in at install time. Now someone finds a remote root vulnerability in the go-openssl library. I know some of the packages I have installed were built against it. What do I do? Use slot-operator := deps, together with the emerge --with-bdeps=y option. Then, if you bump the sub-slot of the go-openssl library, all of your go packages that have it in DEPEND with a slot-operator := dependency will be rebuilt automatically. At least with the useless dev-go/go-openssl installed, I can use subslots to rebuild everything after an upgrade to the fixed version. As I mentioned in my reply to William [1], we might invent a notion of having one ebuild execute another ebuild in order to install static dependencies into a temporary build directory. That way, static libraries would be built on-demand, and discarded as soon as possible. [1] https://archives.gentoo.org/gentoo-dev/message/4b150fe36bf9e0ba1eb29b1d695a3193 -- Thanks, Zac
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 11:25 AM, Michael Orlitzky wrote: On 06/30/2015 02:12 PM, Zac Medico wrote: Suppose ten years from now everything is written in Go. I have 500 statically linked Go packages on my system, all of whose dependencies were built and compiled-in at install time. Now someone finds a remote root vulnerability in the go-openssl library. I know some of the packages I have installed were built against it. What do I do? Use slot-operator := deps, together with the emerge --with-bdeps=y option. Then, if you bump the sub-slot of the go-openssl library, all of your go packages that have it in DEPEND with a slot-operator := dependency will be rebuilt automatically. Right, and now what if go-openssl was built on-the-fly 500 times and there's no package for it? Yeah that's obviously sub-optimal, and it's the reason why I created the dev-go/* ebuilds. However, we may want to distinguish between libraries that would only have a single consumer and libraries that would have multiple consumers. Using the same rules regardless of the number of consumers is not necessarily optimal. -- Thanks, Zac
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 11:12 AM, Zac Medico wrote: As I mentioned in my reply to William [1], we might invent a notion of having one ebuild execute another ebuild in order to install static dependencies into a temporary build directory. That way, static libraries would be built on-demand, and discarded as soon as possible. [1] https://archives.gentoo.org/gentoo-dev/message/4b150fe36bf9e0ba1eb29b1d695a3193 I should note that I'm not very fond of this idea. If the dependencies have separate ebuilds (like dev-go/*), then you can already use something like 'emerge --depclean --with-bdeps=n' to remove the static libraries that aren't needed at run-time. -- Thanks, Zac
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 02:12 PM, Zac Medico wrote: Suppose ten years from now everything is written in Go. I have 500 statically linked Go packages on my system, all of whose dependencies were built and compiled-in at install time. Now someone finds a remote root vulnerability in the go-openssl library. I know some of the packages I have installed were built against it. What do I do? Use slot-operator := deps, together with the emerge --with-bdeps=y option. Then, if you bump the sub-slot of the go-openssl library, all of your go packages that have it in DEPEND with a slot-operator := dependency will be rebuilt automatically. Right, and now what if go-openssl was built on-the-fly 500 times and there's no package for it?
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 08:35 AM, William Hubbs wrote: All, we have digressed a bit, so I want to bring the discussion back to what my main concerns are about this issue. 1. Should we bundle Go packages with Go software? If we do, except for the Go standard library which is part of dev-lang/go, do we need to bother with installing Go sources and packages at all? The down side of the whole bundling idea is that every consumer on someone's system could potentially have a different version of the Go package, which doesn't lend itself well to security concerns. This is why bundling is generally discouraged in Gentoo. Yes, as a general rule, bundling is sub-optimal. However, there are often exceptions to general rules like these, especially when there are competing concerns to contend with. Also, if we bundle, most of dev-go/* doesn't need to exist because these libraries would be bundled into and statically linked into the software that needs them. Some static libraries are commonly used enough that it might be reasonable to install them. Alternatively, we might invent a notion of having one ebuild execute another ebuild in order to install static dependencies into a temporary build directory. 2. How should we bundle? This is where my concern about consul and some other ebuilds comes in. The way the consul ebuild is written (putting the commit hashes of dependencies in SRC_URI) assumes that all of the dependencies will stay on github. This makes the ebuild far less flexable than go itself is. Agreed. However, there's no rule which says that we have to force all ebuilds to fit into common templates. If we are going to bundle, I would rather have one tarball that includes all of the sources for consul and the dependent libraries dropped on the Gentoo mirrors. Such a tarball is very easy to create. I would prefer to use separate tarballs for each dependency, preferably with the commit hash encoded in the tarball name. This makes the ebuild dependencies transparent in the sense that the commit hashes of the dependencies are readily available. The one big tarball is opaque rather than transparent, and it will have a tendency bloat the mirrors. By keeping the dependencies in separate tarballs, we can easily do a revbump that updates a subset of the dependencies, without having to re-pack everything into a big bloated tarball. -- Thanks, Zac
Re: [gentoo-dev] NPM / NodeJS project
FWIW, I also bumped into this in my previous job. I even wrote this (https://github.com/neurogeek/g-npm) which is incomplete but saved me a bunch of time creating a crazy amount of npm ebuilds. kinda rant My experience is, this isn't worth it. npm is a mess, is maintainer-unfriendly (although it might be argued that it is developer-friendly) and they basically don't care about about distributions at all. npm packages are not meant to be installed globally. They are content with having duplicate dependencies laying around everywhere. Their semantic versioning sucks. They 1.4.1.2 can break backwards compatibility with 1.4.1.1 and nobody cares. I didn't find a way to download specific versions, and had trouble when they did stuff like depend on 1.4.x, because of the above. Also, although minor point, the other reason I stopped pursuing this was because I think npm packages are needlessly small. So, you might want to install a package that depends on tens of other packages that depend on tens of packages themselves. Most of this packages are 10 lines of code. So, I ended up real fat with an dev-nodejs category with over a hundred packages. /kinda rant Having said all that, this was at least a couple of years ago. They might have come to their senses by now. Cheers, On Tue, Jun 30, 2015 at 10:06 AM, Michael Orlitzky m...@gentoo.org wrote: On 06/30/2015 03:56 AM, Ian Delaney wrote: Is this what I prompted about a year or more ago, and drew no interest in pursuing the npm path? I cited an eclass called npm.eclass in a dev's overlay. The conclusion was that using npm to install anything competed with portage at a level that made it a 'no go'. This came from members of the portage 'team'. It is a very awkward topic. No, but we may have wound up with a similar idea. I only became interested last week when somebody gave me a coffeescript program to deploy at work and there was no coffeescript. My eclass isn't using npm to do the actual install, since npm won't do a global install. I am using it as a lazy way to run the test suite (npm test), and I'm defaulting to npmjs.org as HOMEPAGE/SRC_URI because they have nice predictable URLs. But the src_install manually copies the javascript bits to a location where node can find them. -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote:
On 06/30/2015 08:35 AM, William Hubbs wrote:
All,
we have digressed a bit, so I want to bring the discussion back to what
my main concerns are about this issue.
1. Should we bundle Go packages with Go software?
If we do, except for the Go standard library which is part of
dev-lang/go, do we need to bother with installing Go sources and
packages at all?
The down side of the whole bundling idea is that every consumer
on someone's system could potentially have a different version of the
Go package, which doesn't lend itself well to security concerns.
This is why bundling is generally discouraged in Gentoo.
Yes, as a general rule, bundling is sub-optimal. However, there are
often exceptions to general rules like these, especially when there are
competing concerns to contend with.
I don't really see what the competing concerns are in this case.
Also, if we bundle, most of dev-go/* doesn't need to exist because these
libraries would be bundled into and statically linked into the software
that needs them.
Some static libraries are commonly used enough that it might be
reasonable to install them. Alternatively, we might invent a notion of
having one ebuild execute another ebuild in order to install static
dependencies into a temporary build directory.
Why do we need to worry about how many projects use a library? Upstream
has it as a library for good reason, so that multiple projects can use
it. If upstream installs it as a library, that's how we should install
it if we install it.
The problem I see with the argument about commonly used enough is the
vagueness of it. If we have two packages that use a library, it is
commonly used enough that it should be installed separately.
If we start out bundling libraries, especially libraries from different
upstreams than the package we are working on, that forces all go
maintainers to check all go ebuilds in the tree to see if multiple
bundling is going on and open bugs to create separate ebuilds for
libraries that were only used before by one package but now are used by
more than one.
2. How should we bundle?
This is where my concern about consul and some other ebuilds comes in.
The way the consul ebuild is written (putting the commit hashes of
dependencies in SRC_URI) assumes that all of the dependencies will stay
on github. This makes the ebuild far less flexable than go itself is.
Agreed. However, there's no rule which says that we have to force all
ebuilds to fit into common templates.
We do when they deal with common issues; that's the whole point of
language-based eclasses, e.g. ruby* perl* and python*.
If we are going to bundle, I would rather have one tarball that includes
all of the sources for consul and the dependent libraries dropped on the
Gentoo mirrors. Such a tarball is very easy to create.
I would prefer to use separate tarballs for each dependency, preferably
with the commit hash encoded in the tarball name. This makes the ebuild
dependencies transparent in the sense that the commit hashes of the
dependencies are readily available. The one big tarball is opaque
rather than transparent, and it will have a tendency bloat the mirrors.
By keeping the dependencies in separate tarballs, we can easily do a
revbump that updates a subset of the dependencies, without having to
re-pack everything into a big bloated tarball.
I can agree with part of this; one big tarball is less transparent than
multiple tarballs.
Another thing to consider is, with one big tarball, you can name the
extraction directory to match ${S}, which means there would be no need
for magic in the ebuilds to deal with putting extracted directories in
the right place.
All I'm saying is, if we are going to bundle, lets go all in and not
download multiple upstream packages in src_uri but put them in big
tarballs.
If we are not going to bundle, the best way to handle it is to not
bundle at all imo.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/06/2015 05:25, Zac Medico wrote: On 06/29/2015 07:24 PM, Michael Orlitzky wrote: On 06/29/2015 07:44 PM, Zac Medico wrote: Having faced the exact same problem I have to say I agree 100% with Zac. I'd like to say that Gentoo needs this kind of packages to stay actual and that our NOGO (yes that's an actual joke) on Go packages is not good for us nowdays. While it would certainly be possible to split out a number of separate ebuilds for Go libraries that are used *exclusively* by consul, what advantages would it have? Even in this limiting case, 1. You avoid pointless rebuilds. You rebuild the library (and probably the binary, for Go packages) when the library is upgraded rather than rebuilding everything whenever anything is updated. From my experience, Go packages don't take very long to build. +1, Go is not C, I have the same feeling 2. Security. If upstream treats the packages as separate, a user might hear that there's a security issue in libfoo but then run eix and see that he doesn't have libfoo installed (because it's bundled). That's a reasonable motivation. However, many of these libraries don't have any tags. So, you'll have to use the commit hashes if you want to test for vulnerabilities. In the case of the consul ebuild, the commit hashes of the libraries are available in the SRC_URI. I suppose that we could standardize a way to expose these. +1, there is no strong tagging on every upstream. Maybe that's another topic but handling git sub modules et al could be made easier while satisfying our QA (or maybe make some exceptions) 3. Chicken and egg problem. If the library only has one consumer and you keep it bundled with that consumer forever, then it will probably only ever have one consumer. If somebody wants to use it in an overlay or something he'd have to pull in the whole program. If a Go developer wants to use the libraries in question, then he'll probably use 'go get' to install them. I doubt the existence of an ebuild will have much relevance in people's decision to adopt a given Go library. 4. Ebuild complexity. Now you have to compile e.g. three packages in src_compile, install three packages in src_install, etc. The result is more complicated than building once, three times. In the case of the consul ebuild, all of the libraries are automatically built when the ebuild calls the emake. Even without a Makefile, Go makes it trivial to build the dependencies. Non live GIT ebuilds already make ebuilds more complex, this should indeed be enough. 5. One maintainer has to commit to maintaining all of the dependencies in addition to the program that he cares about. I guess that's a reasonable argument, depending on how much maintenance the dependencies require. Since there is no real Go support as such, this would be a pain ... Someone actually has to do the work to split out the libraries, so it may not be a clear-cut win in some cases. But it's nicer to have them split out should that happen by magic. Considering that Go binaries are statically linked, you'll end up with a bunch of Go libraries installed that you don't need during run-time. +1, this defeats Go's main advantage imho (not that I think it's smart, but it's the actual fact) Cheers
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 01:30 PM, William Hubbs wrote: On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote: On 06/30/2015 08:35 AM, William Hubbs wrote: All, we have digressed a bit, so I want to bring the discussion back to what my main concerns are about this issue. 1. Should we bundle Go packages with Go software? If we do, except for the Go standard library which is part of dev-lang/go, do we need to bother with installing Go sources and packages at all? The down side of the whole bundling idea is that every consumer on someone's system could potentially have a different version of the Go package, which doesn't lend itself well to security concerns. This is why bundling is generally discouraged in Gentoo. Yes, as a general rule, bundling is sub-optimal. However, there are often exceptions to general rules like these, especially when there are competing concerns to contend with. I don't really see what the competing concerns are in this case. The competing concern is that un-bundling has some possibly undesirable consequences, mainly that it means we'll be installing static libraries that were only intended to be temporary build artifacts. It makes sense to install them if there are multiple consumers, otherwise it doesn't make much sense. Also, if we bundle, most of dev-go/* doesn't need to exist because these libraries would be bundled into and statically linked into the software that needs them. Some static libraries are commonly used enough that it might be reasonable to install them. Alternatively, we might invent a notion of having one ebuild execute another ebuild in order to install static dependencies into a temporary build directory. Why do we need to worry about how many projects use a library? If you want to clutter the tree with trivial ebuilds that only have a single consumer, then I guess that's fine. It's not clear to me that this is the best course of action, but I'm not going to try to stop you if that's what you want to do. Upstream has it as a library for good reason, so that multiple projects can use it. If upstream installs it as a library, that's how we should install it if we install it. I don't think that consul upstream installs it as a library. The last time that I checked upstream's build from source instructions, the consul binary was the only result of interest, so all of the temporary build artifacts could simply be discarded after the consul binary had been built. The problem I see with the argument about commonly used enough is the vagueness of it. If we have two packages that use a library, it is commonly used enough that it should be installed separately. As soon as you have at least two consumers, then you have a good reason to un-bundle a library. If there's only one consumer, then un-bundling becomes questionable. If we start out bundling libraries, especially libraries from different upstreams than the package we are working on, that forces all go maintainers to check all go ebuilds in the tree to see if multiple bundling is going on and open bugs to create separate ebuilds for libraries that were only used before by one package but now are used by more than one. Nobody is being forced to do anything. If a maintainer of a Go package than bundles libraries is doing a version bump, then it would be a good time for him to check if ebuilds have been created for any of those bundled dependencies, and un-bundle them at that point. 2. How should we bundle? This is where my concern about consul and some other ebuilds comes in. The way the consul ebuild is written (putting the commit hashes of dependencies in SRC_URI) assumes that all of the dependencies will stay on github. This makes the ebuild far less flexable than go itself is. Agreed. However, there's no rule which says that we have to force all ebuilds to fit into common templates. We do when they deal with common issues; that's the whole point of language-based eclasses, e.g. ruby* perl* and python*. There can always be outliers that don't fit your existing templates. If we are going to bundle, I would rather have one tarball that includes all of the sources for consul and the dependent libraries dropped on the Gentoo mirrors. Such a tarball is very easy to create. I would prefer to use separate tarballs for each dependency, preferably with the commit hash encoded in the tarball name. This makes the ebuild dependencies transparent in the sense that the commit hashes of the dependencies are readily available. The one big tarball is opaque rather than transparent, and it will have a tendency bloat the mirrors. By keeping the dependencies in separate tarballs, we can easily do a revbump that updates a subset of the dependencies, without having to re-pack everything into a big bloated tarball. I can agree with part of this; one big tarball is less transparent than multiple tarballs. Another thing to consider is, with one
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 03:08 PM, William Hubbs wrote: On Tue, Jun 30, 2015 at 02:34:52PM -0700, Zac Medico wrote: On 06/30/2015 01:30 PM, William Hubbs wrote: I don't really see what the competing concerns are in this case. The competing concern is that un-bundling has some possibly undesirable consequences, mainly that it means we'll be installing static libraries that were only intended to be temporary build artifacts. It makes sense to install them if there are multiple consumers, otherwise it doesn't make much sense. Thinking about this, there may be a third option. This would take a slight reworking of the golang-build.eclass, but that is easy to do, and it would possibly remove the subslot from the dependencies. The source code is where the compatibility between versions of Go is, not the static objects, so what if, for third-party go packages, we skip installing the static objects? If we did this with consul, for example, then the source code for all those libraries (that have no other consumers) would have to be installed in order to build consul-template against the consul's api library. It would be similar to a header dependency. This would necessitate the introduction of build-against dependencies [1], or equivalent virtuals (like virtual/podofo-build). The only down side of this would be that there might be longer rebuilds if the packages have multiple consumers, but it gets rid of the static objects. What do you think? Considering the similarity to header dependencies, I don't know. The subslot thing seems slightly more appealing to me. [1] https://bugs.gentoo.org/show_bug.cgi?id=392239 -- Thanks, Zac
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On Tue, Jun 30, 2015 at 02:34:52PM -0700, Zac Medico wrote: On 06/30/2015 01:30 PM, William Hubbs wrote: On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote: On 06/30/2015 08:35 AM, William Hubbs wrote: All, we have digressed a bit, so I want to bring the discussion back to what my main concerns are about this issue. 1. Should we bundle Go packages with Go software? If we do, except for the Go standard library which is part of dev-lang/go, do we need to bother with installing Go sources and packages at all? The down side of the whole bundling idea is that every consumer on someone's system could potentially have a different version of the Go package, which doesn't lend itself well to security concerns. This is why bundling is generally discouraged in Gentoo. Yes, as a general rule, bundling is sub-optimal. However, there are often exceptions to general rules like these, especially when there are competing concerns to contend with. I don't really see what the competing concerns are in this case. The competing concern is that un-bundling has some possibly undesirable consequences, mainly that it means we'll be installing static libraries that were only intended to be temporary build artifacts. It makes sense to install them if there are multiple consumers, otherwise it doesn't make much sense. Thinking about this, there may be a third option. This would take a slight reworking of the golang-build.eclass, but that is easy to do, and it would possibly remove the subslot from the dependencies. The source code is where the compatibility between versions of Go is, not the static objects, so what if, for third-party go packages, we skip installing the static objects? The only down side of this would be that there might be longer rebuilds if the packages have multiple consumers, but it gets rid of the static objects. What do you think? William signature.asc Description: Digital signature
Re: [gentoo-dev] Packages up for grabs
Hi Daniel, On 06/20/2015 05:35 AM, Daniel zlg Campbell wrote: Sorry for not replying sooner; my client didn't seem to reflect folder updates... Are there any urgent bugs right now? I'm moving tomorrow and won't be able to tend to them if so, but I am interested in taking maintainership of it. I'm expecting to have Internet in my new home within a few weeks. There is a version bump bug (547460) and two other bugs. The version bump would be nice to do now (may be I will try to ask somebody to help me with it, as I have no amd64 hardware now). signature.asc Description: OpenPGP digital signature
