[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Fri, 3 Jan 2014 00:53:17 +0100 Ulrich Mueller wrote: > > On Thu, 2 Jan 2014, Ryan Hill wrote: > > > In case it's helpful here's what FOSSology[1] has to say about some > > common packages that people have uploaded to their demo server. > > I don't get your point here. The licenses of a package have to be > checked in any case. Why would it be more complicated to check the > full set of files in the tarball, instead of the subset of files that > the package will actually install? I was trying to see how many packages contain licenses that aren't already in LICENSES, assuming these would be ones that we would have to have a srcdist USE flag for. Rich said that is was rare. I'm finding every package I've checked so far would need one. Either way I don't care what you do. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 06:02, Luis Ressel wrote: > These are good arguments. Just to be clear: Would you favor if the > default setup did this separation? I personally also like the idea, but > I'd prefer to leave the default at "one distdir for *", and just make > it configurable via the proposed variables. > Yeah, that seems fine to have them all default to the same directory, and document that end users can set these variables and get certain reactions. The only ambiguity I think creeps in is when you're say, jdk, and you're telling users to download a file to a directory somewhere, you want to tell them "Download to ${DISTDIR_NOFETCH}" , which may not necessarily be available in all PMS implementations, and there's no real way around that. As it is,we have the best I could expect, pkg_nofetch() + error message, because you can't really give a generic response to RESTRICT=fetch , because fetch restrictions are not straight forward to resolve, and the only plausible way to enhance on this circumstnace would be to have a standard PMS feature that appended to the pkg_nofetch() with a list paths it was expecting to exist. Not to mention, supporting "Check all of $DISTDIR/$NOFETCH/$NOMIRROR" would be a nightmare, because it appears lots of ebuilds manually use the $DISTDIR variable, and would have to be ported somehow to use the new variables. find /usr/portage/ -name "*.ebuild" -print0 | xargs -0 -P3 grep 'DISTDIR' -l | wc -l > 1523 So essentially, the feature set I've suggested have rather complex implications that I can't see being entirely viable without it being a future EAPI feature. There's ways of smoothing this out in portage land by dynamically changing where DISTDIR points, but thats a similarly ugly problem. -- Kent
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
> On Thu, 2 Jan 2014, Ryan Hill wrote: > In case it's helpful here's what FOSSology[1] has to say about some > common packages that people have uploaded to their demo server. I don't get your point here. The licenses of a package have to be checked in any case. Why would it be more complicated to check the full set of files in the tarball, instead of the subset of files that the package will actually install? Ulrich > [1] http://www.fossology.org/projects/fossology pgpDS40rx2lsP.pgp Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 16:07:22 -0600 Ryan Hill wrote: > On Thu, 2 Jan 2014 16:20:09 -0500 > Rich Freeman wrote: > > Personally I don't have any use for ACCEPT_LICENSE at all, and having > > to specify the LICENSE for every single package in the tree is a lot > > more work than additionally specifying additional licenses for the > > rare tarball that contains extra stuff under a different license that > > we don't install. I don't really see a downside to this approach - if > > you don't need the extra info then don't look at it - it won't pertain > > to 98% of the packages in portage anyway. > > I don't think it's that rare, but I don't know. To find out for sure we'd > have to check every distfile we distribute. :p In case it's helpful here's what FOSSology[1] has to say about some common packages that people have uploaded to their demo server. gcc-4.7.2.tar ACAA ,ATT ,BSD ,BSD-2-Clause ,BSD-3-Clause ,BSD-lite ,BSD-possibility ,BSD-style ,BSL-1.0 ,CC-BY-SA-3.0 ,CPL ,Docbook ,Dual-license ,FSF ,FSF-possibility ,GFDL-1.1 ,GFDL-1.2+ ,GFDL-1.3 ,GNU-Manpages ,Gov't-rights ,GPL ,GPL-2.0 ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception ,GPL-2.0-with-bison-exception ,GPL-2.0-with-classpath-exception ,GPL-3.0 ,GPL-3.0+ ,GPL-3.0-with-autoconf-exception ,GPL-3.0-with-GCC-exception ,GPL-exception ,GPL-possibility ,IETF ,info-zip ,IPL-1.0 ,ISC ,JPEG/netpbm ,LGPL ,LGPL-2.0+ ,LGPL-2.1 ,LGPL-2.1+ ,LGPL-3.0 ,LGPL-3.0+ ,Microsoft-possibility ,MIT ,MIT-style ,MPL-1.1 ,No_license_found ,Non-commercial! ,Non-profit! ,NOT-public-domain ,NotreDame-style ,Public-domain ,Public-domain-ref ,Same-license-as ,SAX-PD ,See-doc(OTHER) ,See-file(COPYING) ,See-file(README) ,Sun-possibility ,SunPro ,Sun(tm) ,TeX-exception ,Trademark-ref ,UnclassifiedLicense ,W3C ,W3C-IP ,W3C-possibility ,W3C-style ,X11 ,X11-possibility ,Zlib ,Zlib-possibility eglibc-2.17 Artistic-1.0 ,BSD-3-Clause ,BSD-lite ,BSD-style ,BSL-1.0 ,Cisco-style ,CMU ,FSF ,GNU-style(EXECUTE) ,GPL ,GPL-2.0 ,GPL-2.0+ ,GPL-3.0+ ,GPL-3.0+-with-bison-exception ,GPL-exception ,GPL-possibility ,IBM ,IBM-possibility ,IETF ,InnerNet-2.00 ,ISC ,LGPL ,LGPL-2.0 ,LGPL-2.0+ ,LGPL-2.1 ,LGPL-2.1+ ,LGPL-3.0+ ,LGPL-possibility ,Microsoft-possibility ,MIT ,MIT-style ,No_license_found ,Oracle-Berkeley-DB ,Public-domain ,Public-domain-ref ,Same-license-as ,See-doc(OTHER) ,Sun-possibility ,SunPro ,Trademark-ref ,X11-possibility apache2 version 2.2 Apache-2.0 ,Apache-possibility ,Bellcore ,BSD-2-Clause ,BSD-3-Clause ,BSD-4-Clause-UC ,BSD-possibility ,Cisco ,CMU ,FSF ,GPL ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception ,GPL-exception ,ISC ,MIT ,MIT-style ,MPL ,No_license_found ,OLDAP ,Public-domain ,Public-domain-ref ,RSA-Security ,See-doc(OTHER) ,See-file(COPYING) ,See-file(LICENSE) ,Zeus ,Zlib Ghostscript AFPL-Ghostscript ,Aladdin(Closed-Source!) ,Aladdin-Ghostscript ,ATT-style ,Bitstream ,BSD-style ,GNU-Ghostscript ,GPL ,GPL-2.0+ ,No_license_found ,Not-for-sale! ,NOT-public-domain ,Public-domain ,See-doc(OTHER) ,UnclassifiedLicense ,zlib/libpng Perl Apache-2.0 ,Artistic ,Artistic-2.0 ,Artistic-possibility ,Bellcore ,BSD ,BSD-lite ,BSD-possibility ,BSD-style ,FSF ,GFDL-1.1 ,GPL ,GPL-1.0 ,GPL-1.0+ ,GPL-2.0+ ,GPL-3.0 ,GPL-Bison-exception ,LGPL ,LGPL-2.1 ,LGPL-3.0 ,MIT ,MIT-possibility ,MIT-style ,MPL ,MPL-1.1 ,No_license_found ,Non-commercial! ,Perl-possibility ,Public-domain ,Public-domain-ref ,RSA-Security ,Same-license-as ,See-doc(OTHER) ,See-file(LICENSE) ,See-file(README) ,Trademark-ref ,UnclassifiedLicense ,Unicode ,zlib/libpng ,zlib/libpng-possibility util-linux-2.23.1.tar BSD ,BSD-3-Clause ,BSD-4-Clause ,BSD-lite ,BSD-style ,Debian-SPI-style ,FSF ,FSF-possibility ,GNU-Manpages ,GPL ,GPL-1.0+ ,GPL-2.0 ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception ,GPL-3.0+ ,GPL-exception ,LGPL ,LGPL-2.0 ,LGPL-2.0+ ,LGPL-2.0-possibility ,LGPL-2.1 ,LGPL-2.1+ ,MIT ,MIT-style ,No_license_found ,NOT-public-domain ,Public-domain ,Public-domain(C) ,Public-domain-ref ,Same-license-as ,UnclassifiedLicense ,X11 [1] http://www.fossology.org/projects/fossology -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 16:20:09 -0500 Rich Freeman wrote: > On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill wrote: > > That's only possible if we enumerate every license in every distfile we > > distribute, which I don't think is a good idea. Or at least not on the > > basis of a theoretic user that might not actually exist. > > Why would we need to do that when we don't specify a LICENSE for every > single file we install from a package. LICENSE is a string of > licenses that apply to all of the files installed by a package, and > USE=srcdist LICENSE is a string of licenses that apply to all of the > SRC_URIs. That's what I said (or meant I guess). When I say distfile it means tarball/SRC_URI. In order to make a decision about what distfiles you will allow on your system, you need to know the licenses in those distfiles. So we would have to list all the licenses in that distfile, whether they apply or not. > Personally I don't have any use for ACCEPT_LICENSE at all, and having > to specify the LICENSE for every single package in the tree is a lot > more work than additionally specifying additional licenses for the > rare tarball that contains extra stuff under a different license that > we don't install. I don't really see a downside to this approach - if > you don't need the extra info then don't look at it - it won't pertain > to 98% of the packages in portage anyway. I don't think it's that rare, but I don't know. To find out for sure we'd have to check every distfile we distribute. :p -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill wrote: > That's only possible if we enumerate every license in every distfile we > distribute, which I don't think is a good idea. Or at least not on the > basis of a theoretic user that might not actually exist. Why would we need to do that when we don't specify a LICENSE for every single file we install from a package. LICENSE is a string of licenses that apply to all of the files installed by a package, and USE=srcdist LICENSE is a string of licenses that apply to all of the SRC_URIs. Personally I don't have any use for ACCEPT_LICENSE at all, and having to specify the LICENSE for every single package in the tree is a lot more work than additionally specifying additional licenses for the rare tarball that contains extra stuff under a different license that we don't install. I don't really see a downside to this approach - if you don't need the extra info then don't look at it - it won't pertain to 98% of the packages in portage anyway. Rich
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius wrote: > On 02/01/14 07:50 AM, Ryan Hill wrote: > > > > Maybe we could add RESTRICT=srcdist which would cause ebuilds to > > save their distfiles in a separate directory controlled by > > PORTDIR_NODIST or something. If the variable is unset then it's > > business as usual. > > > > ..or we could just do this, using the existing RESTRICT="mirror" > that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR, > NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then > distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR. This I like (except the name, but mine sucks too ;p). Portage should probably check both dirs when searching for distfiles so it can find manually fetched files the user may have dropped into the wrong one, and also to maybe warn if sources are found in distdir for a mirror-restricted package (or just move them to the right place itself). -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 19:17:50 +0100 Ulrich Mueller wrote: > > On Thu, 2 Jan 2014, Luis Ressel wrote: > > >> RESTRICT is somewhat complementary to LICENSE and cannot provide as > >> much information. Especially, RESTRICT="mirror" doesn't say under > >> what license the restricted pieces are, and doesn't allow for > >> ACCEPT_LICENSE filtering. > > > But is this detailed information really neccessary? The use-case is > > ensuring the legality of distfiles mirroring -- you're either > > allowed to do it nor not, the exact license doesn't matter here. > > This is not primarily about distfiles mirroring, about about giving > users a choice what distfiles they will accept on their systems (for > whatever reasons, e.g. legal or philosophical). Besides, not all users > are under the same legislation, which may affect their choice. Well, your subject line says "srcdist" ;). That's only possible if we enumerate every license in every distfile we distribute, which I don't think is a good idea. Or at least not on the basis of a theoretic user that might not actually exist. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
> On Thu, 2 Jan 2014, Ulrich Mueller wrote: > This is not primarily about distfiles mirroring, about about giving s/about about/but about/ > users a choice what distfiles they will accept on their systems (for > whatever reasons, e.g. legal or philosophical). Besides, not all > users are under the same legislation, which may affect their choice.
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, Jan 2, 2014 at 1:17 PM, Ulrich Mueller wrote: > > This is not primarily about distfiles mirroring, about about giving > users a choice what distfiles they will accept on their systems (for > whatever reasons, e.g. legal or philosophical). Besides, not all users > are under the same legislation, which may affect their choice. ++ One could argue we don't need LICENSE at all since RESTRICT=mirror already tells you something. Gentoo is about choice and this is just one more choice we're giving users. The proposal is a NOOP for anybody who doesn't do anything special, and those who want to use the new flag can do so. It also helps document the state of the tree so that when we look at some ebuild and wonder why it is set to RESTRICT=mirror we have more clues. Rich
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 02 Jan 2014 12:13:47 -0500 Ian Stakenvicius wrote: > RESTRICT="fetch" requires the user to do their own fetching; since > they're doing that, it should be pretty obvious that the distfile is > restricted somehow. Of course, they are still able to do whatever > they want, but I expect anyone that is keeping DISTDIR and > NODISTCACHEDIR as separate targets would know to not place the fetched > distfile in their self-distributing directory, or at least know to > read the license restrictions already present in the listed LICENSEs Yes, I totally forgot that. Portage doesn't download these files, so there's no point in creating a variable telling it where to put them... Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
> On Thu, 2 Jan 2014, Luis Ressel wrote: >> RESTRICT is somewhat complementary to LICENSE and cannot provide as >> much information. Especially, RESTRICT="mirror" doesn't say under >> what license the restricted pieces are, and doesn't allow for >> ACCEPT_LICENSE filtering. > But is this detailed information really neccessary? The use-case is > ensuring the legality of distfiles mirroring -- you're either > allowed to do it nor not, the exact license doesn't matter here. This is not primarily about distfiles mirroring, about about giving users a choice what distfiles they will accept on their systems (for whatever reasons, e.g. legal or philosophical). Besides, not all users are under the same legislation, which may affect their choice. Ulrich pgpUAkgIM_KBT.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/01/14 11:28 AM, Luis Ressel wrote: > On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius > wrote: > >> ..or we could just do this, using the existing RESTRICT="mirror" >> that's already in ebuilds -- have a DISTDIR and a >> NODISTCACHEDIR, NODISTCACHEDIR defaults to DISTDIR; if >> RESTRICT="mirror" then distfiles are saved to NODISTCACHEDIR, >> otherwise are saved to DISTDIR. > > IMHO, this is the best solution proposed so far. It doesn't need a > new USE flag duplicating information which is already in RESTRICT > (or am I missing some corner cases here?), and it doesn't bother > those who don't care about this issue with new distfiles-*/ dirs, > as with Kent's proposal. > > @Kent: Why do you think another distinction for RESTRICT=fetch is > neccessary? If it really is, it could also be integrated into this > solution, but I don't get the point -- either you're allowed to > redistribute it, or you're not. RESTRICT=fetch just signals > Portage that it won't be *technically* able to download the > distfiles. > > > Luis > RESTRICT="fetch" requires the user to do their own fetching; since they're doing that, it should be pretty obvious that the distfile is restricted somehow. Of course, they are still able to do whatever they want, but I expect anyone that is keeping DISTDIR and NODISTCACHEDIR as separate targets would know to not place the fetched distfile in their self-distributing directory, or at least know to read the license restrictions already present in the listed LICENSEs -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlLFnksACgkQ2ugaI38ACPCI6gEAmBwKJ3+ce0zkrimGeb6oORVv a2WteMNC9VVeZ+Jce4oA/2ys6+VPZ5AGheVrfL9eakupDPGwbxif78qC6PQ2D28k =gqBF -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 17:53:45 +0100 Ulrich Mueller wrote: > RESTRICT is somewhat complementary to LICENSE and cannot provide as > much information. Especially, RESTRICT="mirror" doesn't say under > what license the restricted pieces are, and doesn't allow for > ACCEPT_LICENSE filtering. But is this detailed information really neccessary? The use-case is ensuring the legality of distfiles mirroring -- you're either allowed to do it nor not, the exact license doesn't matter here. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Fri, 3 Jan 2014 05:37:33 +1300 Kent Fredric wrote: > Fair point. I was more seeing a pattern emerging and exploring where > that might lead. > > Though I figure it a useful distinction for convenience sake. > > Consider if you wanted to archive some files to make a subsequent > gentoo installation easier. > > It would be optimal to backup and replicate the nofetch directory for > the subsequent installation, because that's the only directory that > portage would be unable to populate itself from upstream sources. > > so it becomes: > > /distfiles # Gentoo Replicated and Fetchable from upstream > /distfiles-normirror # Fetch from upstream only > /distfiles-nofetch # manual fetching only > > So it was more a practical benefit than a legal one =). > > ( Also if you were tight on space, you'd obliterate distfiles/ first, > distfiles-nomirror/ second, and distfiles-nofetch/ last ) These are good arguments. Just to be clear: Would you favor if the default setup did this separation? I personally also like the idea, but I'd prefer to leave the default at "one distdir for *", and just make it configurable via the proposed variables. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
> On Thu, 2 Jan 2014, Luis Ressel wrote: > IMHO, this is the best solution proposed so far. It doesn't need a > new USE flag duplicating information which is already in RESTRICT > (or am I missing some corner cases here?), and it doesn't bother > those who don't care about this issue with new distfiles-*/ dirs, as > with Kent's proposal. RESTRICT is somewhat complementary to LICENSE and cannot provide as much information. Especially, RESTRICT="mirror" doesn't say under what license the restricted pieces are, and doesn't allow for ACCEPT_LICENSE filtering. Ulrich pgp8RYngpebjb.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 05:28, Luis Ressel wrote: > > @Kent: Why do you think another distinction for RESTRICT=fetch is > neccessary? If it really is, it could also be integrated into this > solution, but I don't get the point -- either you're allowed to > redistribute it, or you're not. RESTRICT=fetch just signals Portage > that it won't be *technically* able to download the distfiles. Fair point. I was more seeing a pattern emerging and exploring where that might lead. Though I figure it a useful distinction for convenience sake. Consider if you wanted to archive some files to make a subsequent gentoo installation easier. It would be optimal to backup and replicate the nofetch directory for the subsequent installation, because that's the only directory that portage would be unable to populate itself from upstream sources. so it becomes: /distfiles # Gentoo Replicated and Fetchable from upstream /distfiles-normirror # Fetch from upstream only /distfiles-nofetch # manual fetching only So it was more a practical benefit than a legal one =). ( Also if you were tight on space, you'd obliterate distfiles/ first, distfiles-nomirror/ second, and distfiles-nofetch/ last ) -- Kent
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius wrote: > ..or we could just do this, using the existing RESTRICT="mirror" > that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR, > NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then > distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR. IMHO, this is the best solution proposed so far. It doesn't need a new USE flag duplicating information which is already in RESTRICT (or am I missing some corner cases here?), and it doesn't bother those who don't care about this issue with new distfiles-*/ dirs, as with Kent's proposal. @Kent: Why do you think another distinction for RESTRICT=fetch is neccessary? If it really is, it could also be integrated into this solution, but I don't get the point -- either you're allowed to redistribute it, or you're not. RESTRICT=fetch just signals Portage that it won't be *technically* able to download the distfiles. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/01/14 07:50 AM, Ryan Hill wrote: > > Maybe we could add RESTRICT=srcdist which would cause ebuilds to > save their distfiles in a separate directory controlled by > PORTDIR_NODIST or something. If the variable is unset then it's > business as usual. > ..or we could just do this, using the existing RESTRICT="mirror" that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR, NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlLFj44ACgkQ2ugaI38ACPAmmQD/TB04vOHgqsxXsB3pfeIKULL7 jrtgN3G/BHLPGlcL1D0A/i4o5Be+/wbqD+eBG8NPcZgfKOaS8SG4+c0vBZBQNKVl =PilO -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 02:18, Ulrich Mueller wrote: > > Maybe we could add RESTRICT=srcdist which would cause ebuilds to > > save their distfiles in a separate directory controlled by > > PORTDIR_NODIST or something. If the variable is unset then it's > > business as usual. > > Interesting idea, but how would RESTRICT=srcdist be different from > RESTRICT=mirror? > I'd suggest we don't even need multiple variables for this, RESTRICT=mirror seems clear enough. The only change required would be overloading the meaning of that RESTRICT verb to mean new things with regard to disk storage. ie: /distfiles/ # Normal /distfiles-nomirror/ # RESTRICT=mirror /distfiles-nofetch/ # RESTRICT=fetch I guess you could make it still search for distfiles in all 3 locations in case end users want to do silly things like violate Java's mirroring policies and replicate java things via distfiles/ shared, or you could make it straightfoward enough to use all 3 paths with a single distfiles dir. But as it stands, the tooling isn't too friendly for people who want/need to closely adhere to upstream distribution policies. -- Kent
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 01:50, Ryan Hill wrote: > Maybe we could add RESTRICT=srcdist which would cause ebuilds to save > their distfiles in a separate directory controlled by PORTDIR_NODIST or > something. If the variable is unset then it's business as usual. > I was going to suggest similar. Though I hadn't thought about it at a global RESTRICT level, but I had envisioned that potentially, the redistribubility should be a property of a source file, not of en ebuild. For example, if there was something such as java, which would likely be mirror-restricted, it the java binaries themselves would be mirror restricted. However, if there were any tools/patches provided by gentoo and also in src_uri, marking them as no-mirror seems counter productive. Just the RESTRICT based interface seems more obvious, where as spicing SRC_URI values properly could be nuanced and complicated. -- Kent
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
> On Thu, 2 Jan 2014, Ryan Hill wrote: > I've always believed that when it comes down to it all Gentoo > basically does is provide a link to some source code and a script > to build and install it. Unless we violate someone's license by > redistributing that source then we really don't have to worry about > it, and as you said we already have mechanisms to deal with that. > What the user does with that source is their business, and they are > solely responsible for following the terms of the license(s). > IIRC this is the stance we took back in 2006 with the cdrtools > debacle [1]. > [1] http://lwn.net/Articles/199061/ I completely agree with you. > So I don't understand why we would have to remove anything from the > tarballs. Unless there's a license in there that forbids mirroring > then there's no need to list other licenses that aren't relevant. > The user wants to know what conditions he needs to follow to build > and use the package, not what the tarball happen to contain. If you > tell him that he can't install something because of a license on a > piece of code that is never used, built, or installed, he isn't > going to be very happy. IMHO, we normally shouldn't remove anything from tarballs. We have mirror and fetch restrictions which should cover most cases where we are not allowed to redistribute a distfile. > Wouldn't that just prevent you from installing the package > altogether? Some people might be okay with that, but if it's a > package you need then you are forced to choose between either > disabling the USE flag or stop filtering the license for that > package. Either way you end up with non-distributable stuff in your > distfiles. Of course, the srcdist USE flag would be disabled by default, so it would make no difference for users' ACCEPT_LICENSE filtering. See it as a way to provide additional information about license terms of distfiles, or the part of distfiles that is not going to be installed. > Maybe we could add RESTRICT=srcdist which would cause ebuilds to > save their distfiles in a separate directory controlled by > PORTDIR_NODIST or something. If the variable is unset then it's > business as usual. Interesting idea, but how would RESTRICT=srcdist be different from RESTRICT=mirror? Ulrich pgp7lfWsih_Dy.pgp Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 06:50:06 -0600 Ryan Hill wrote: > I've always believed that when it comes down to it all Gentoo basically does > is provide a link to some source code and a script to build and install it. > Unless we violate someone's license by redistributing that source then we > really don't have to worry about it, and as you said we already have > mechanisms to deal with that. What the user does with that source is their > business, and they are solely responsible for following the terms of the > license(s). IIRC this is the stance we took back in 2006 with the cdrtools > debacle [1]. [1] http://lwn.net/Articles/199061/ -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Wed, 1 Jan 2014 23:28:54 +0100 Ulrich Mueller wrote: > Hi, > According to GLEP 23 [1], the LICENSE variable regulates the software > that is installed on a system. There is however some ambiguity in > this: should it cover the actual files installed on the system, or > everything that is included in the package's tarball? This question > was asked several times in the past and arose in bug 492424 [2] again. > > I've always preferred the first interpretation, because the second one > would inevitably require us to repack many tarballs, in order to keep > their license in @FREE. This would for example include the Linux > kernel, where we could no longer use deblobbing, but would have to > provide our own tarball with firmware blobs removed. Not sure if users > would be happy if we wouldn't install from pristine sources any more. > We also have mirror and fetch restrictions which allow us to control > what tarballs we distribute, independent of the LICENSE variable. I've always believed that when it comes down to it all Gentoo basically does is provide a link to some source code and a script to build and install it. Unless we violate someone's license by redistributing that source then we really don't have to worry about it, and as you said we already have mechanisms to deal with that. What the user does with that source is their business, and they are solely responsible for following the terms of the license(s). IIRC this is the stance we took back in 2006 with the cdrtools debacle [1]. So I don't understand why we would have to remove anything from the tarballs. Unless there's a license in there that forbids mirroring then there's no need to list other licenses that aren't relevant. The user wants to know what conditions he needs to follow to build and use the package, not what the tarball happen to contain. If you tell him that he can't install something because of a license on a piece of code that is never used, built, or installed, he isn't going to be very happy. > Within existing EAPIs we have only one LICENSE variable available. > (Extending it would be possible in future EAPIs, but we would end up > with a very long transition period.) USE conditional syntax is allowed > in LICENSE, though. So I wonder if this couldn't be used for the > intended purpose. For example, for specifying licenses of distfiles: > > LICENSE=" > srcdist? ( )" > > This idea was discussed within the licenses team, and the overall > reaction was positive. > > What do you think? Wouldn't that just prevent you from installing the package altogether? Some people might be okay with that, but if it's a package you need then you are forced to choose between either disabling the USE flag or stop filtering the license for that package. Either way you end up with non-distributable stuff in your distfiles. Maybe we could add RESTRICT=srcdist which would cause ebuilds to save their distfiles in a separate directory controlled by PORTDIR_NODIST or something. If the variable is unset then it's business as usual. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature