Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 22/07/2013 01:50, hasufell wrote: It does not apply, because we still support it officially in our main tree as a distribution, no matter if it's p.masked or not. No we don't. P.masked software is *explicitly* not supported. Anyway... if people disagree, then it doesn't make much sense to remove it. Otherwise it will pop up in the tree sooner or later again. Which is a perfect reason to keep it p.maske din tree so that nobody can re-introduce it as they felt it missing. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Mon, 22 Jul 2013 01:26:25 +0200 hasufell hasuf...@gentoo.org wrote: Afaiu pmasks are rather meant for a) new, very hot versions of libraries/tools that can break your system in more than one part b) security masks, temporary masks and other masks we expect to remove in the future You can just summarize all possible reasons, by does not work well; and that's exactly what google-earth falls under as well. So, just go mask it; and as we don't want to remove it just yet we can delay the decision to last rite the package for later. Before we last rite, has anyone tried to collaborate with upstream about their packaging style? And I said more than once that we can probably move it to science-overlay. Overlays aren't the problem here, they'll follow automatically; even with just the mask in place, I think there are people that are going to try to provide it more easily anyway. And the use of a lot of overlay packages isn't really a problem, when said person has a small overlay. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
hasufell posted on Mon, 22 Jul 2013 02:50:04 +0200 as excerpted: [Where to reply? This seems the best spot in general. Subthread is discussing permanent in-tree p.mask vs. overlay. The below points were supposed to be the pros of the overlay choice.] On 07/22/2013 01:49 AM, Diego Elio Pettenò wrote: On 21/07/2013 23:38, hasufell wrote: - consistency of tree quality does not apply to p.mask'd packages p.mask says that the package is in _bad_ quality, explicitly, and you can say how, so does not apply are not really the words I'd use. I did not know that p.mask is used indefinitely for low quality packages and I don't like that concept. Yes, some packages remain in-tree permanently p.masked. The mask gives a reason, and unmasking means users accept whatever risks or conditions you place in the reason. In addition to unmasking, if you REALLY want to discourage use, you can use some variant of the test for pkgname_I_KNOW_WHAT_I_AM_DOING=1 trick. - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree maybe Not p.masked packages they don't. Just state it outright, maybe even fetch-restrict the package and warn them... Absolutely. - less bugs no one can do anything about does not apply *How* does making it into a semi-official one-purpose overlay reduce the number of bugs users report? Either you're banning it into a non-Gentoo-owned overlay, or you're just betting they would get the reason why it's not in an overlay, same applies to p.mask. It will reduce the number of bugs, because there will be no bugtracker, but only pull-requests. It would not be hosted on o.g.o. which means gentoo bugs are not allowed. State in the p.mask that bugs will be ignored and/or that people filing bugs without patches will be summarily laughed at, and be done with it. - easier contribution of users in an overlay, testing of hacks or other stuff to make it work does not apply I'm afraid I have to agree with Michael here. Proxies would do that, and users are still free to experiment with overlaid version, I don't see how this makes much of a difference. Actually, I'll give you (hasufell) this one. This is the one point I agree with, and it may well be enough on its own. Proxies can help, but IMO that's a lot of hassle to go thru for a permanently package-masked package. With an overlay, OTOH, non-dev volunteers can get direct access. - making clear that gentoo does not support software with such low QA does not apply It applies perfectly. It's a p.mask for a reason, and can convey reasons. Agreed with Diego here. If the p.mask message says unsupported, don't file bugs or you'll be summarily laughed at... doesn't get much clearer than that. Anyway... if people disagree, then it doesn't make much sense to remove it. Otherwise it will pop up in the tree sooner or later again. FWIW, I wasn't strongly disagreeing with the removal to overlay or even full removal (I've never used the package and don't have that level of interest). My question was real: Given the context discussing reasons for removal but an intention to continue making it available in an overlay, I simply wondered why the in-tree p.mask option that I'd seen used on a few other packages apparently hadn't even been considered. Now that the option has been discussed, given you're the one that will be continuing the limited maintenance the package will get wherever it is, I've no further objection whatever you choose. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: solution: Treeclean it and maintain it in an overlay (maybe science-overlay). That's exactly what overlays are for... experimental stuff. What's the pros/cons of overlay vs. in-tree-but-masked for something like this? In-tree-but-masked is at least available for those who want it, without having to load an overlay, but I don't see that discussed at all, here. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 12:07 AM, Duncan wrote: hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: solution: Treeclean it and maintain it in an overlay (maybe science-overlay). That's exactly what overlays are for... experimental stuff. What's the pros/cons of overlay vs. in-tree-but-masked for something like this? In-tree-but-masked is at least available for those who want it, without having to load an overlay, but I don't see that discussed at all, here. pros: - consistency of tree quality - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree - less bugs no one can do anything about - easier contribution of users in an overlay, testing of hacks or other stuff to make it work - making clear that gentoo does not support software with such low QA - making clear that this software is experimental cons: - users have to run layman -a foo ...I hope they will manage (and the masking reason will be updated to explain where to look for googleearth ebuilds)
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 11:16 PM, hasufell hasuf...@gentoo.org wrote: pros: - consistency of tree quality - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree - less bugs no one can do anything about - easier contribution of users in an overlay, testing of hacks or other stuff to make it work - making clear that gentoo does not support software with such low QA - making clear that this software is experimental Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe even more than half. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
Dnia 2013-07-22, o godz. 00:16:31 hasufell hasuf...@gentoo.org napisał(a): On 07/22/2013 12:07 AM, Duncan wrote: hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: solution: Treeclean it and maintain it in an overlay (maybe science-overlay). That's exactly what overlays are for... experimental stuff. What's the pros/cons of overlay vs. in-tree-but-masked for something like this? In-tree-but-masked is at least available for those who want it, without having to load an overlay, but I don't see that discussed at all, here. cons: - users have to run layman -a foo ...I hope they will manage (and the masking reason will be updated to explain where to look for googleearth ebuilds) Then to get *a single package* they start using the whole overlay. If it's a sane overlay, fine. But some overlays really replace a lot of stuff silently and trigger failures we didn't even imagine before. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2013 12:33 AM, Michał Górny wrote: Dnia 2013-07-22, o godz. 00:16:31 hasufell hasuf...@gentoo.org napisał(a): On 07/22/2013 12:07 AM, Duncan wrote: hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: solution: Treeclean it and maintain it in an overlay (maybe science-overlay). That's exactly what overlays are for... experimental stuff. What's the pros/cons of overlay vs. in-tree-but-masked for something like this? In-tree-but-masked is at least available for those who want it, without having to load an overlay, but I don't see that discussed at all, here. cons: - users have to run layman -a foo ...I hope they will manage (and the masking reason will be updated to explain where to look for googleearth ebuilds) Then to get *a single package* they start using the whole overlay. If it's a sane overlay, fine. But some overlays really replace a lot of stuff silently and trigger failures we didn't even imagine before. No. I'd either use a separate single-purpose overlay or add it to science-overlay. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR7GI8AAoJEFpvPKfnPDWzVrQH/3o8FrgSaCFpWEAJj1qeFpQP /01wJzMsTV3YWZ9ZqvIZ7txPls+KBlV7hrm0SSNdP5SWO/tdXPllwNu7B+3rdcKN UOP56hlGtRRT2xw1/M/EWX76+hQmMUSYncMJ5kwqWwWGiKYRgJqR6WYH99igxwSV 7OOewcdU9p56l1MY5TxyH0tG/7KkJADSmYCf6xIK7Lkz1yU9G/e2I1WQsMGVnIBR TUkV+q1gM9zDwjKtK64X4rA4l2KiTDfoksyBgSelVMYNPcNEGYZgwmrXCJhKZK7B dYONlBDp/9BG+ihhsNTAXewxsDuVPtXTdFX4dzLciXgGdFw81r+LoNFViH7pRVM= =4JPG -END PGP SIGNATURE-
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 12:22 AM, Diego Elio Pettenò wrote: On Sun, Jul 21, 2013 at 11:16 PM, hasufell hasuf...@gentoo.org wrote: pros: - consistency of tree quality does not apply to p.mask'd packages - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree maybe - less bugs no one can do anything about does not apply - easier contribution of users in an overlay, testing of hacks or other stuff to make it work does not apply - making clear that gentoo does not support software with such low QA does not apply - making clear that this software is experimental applies Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe even more than half.
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote: On 07/22/2013 12:33 AM, Michał Górny wrote: Dnia 2013-07-22, o godz. 00:16:31 hasufell hasuf...@gentoo.org napisał(a): On 07/22/2013 12:07 AM, Duncan wrote: hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: solution: Treeclean it and maintain it in an overlay (maybe science-overlay). That's exactly what overlays are for... experimental stuff. What's the pros/cons of overlay vs. in-tree-but-masked for something like this? In-tree-but-masked is at least available for those who want it, without having to load an overlay, but I don't see that discussed at all, here. cons: - users have to run layman -a foo ...I hope they will manage (and the masking reason will be updated to explain where to look for googleearth ebuilds) Then to get *a single package* they start using the whole overlay. If it's a sane overlay, fine. But some overlays really replace a lot of stuff silently and trigger failures we didn't even imagine before. No. I'd either use a separate single-purpose overlay or add it to science-overlay. If it's a separate overlay, then googleearth overlay in gentoo's github account for easy access for users, both to get and contribute. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/22/2013 01:03 AM, Brian Dolbec wrote: On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote: On 07/22/2013 12:33 AM, Michał Górny wrote: I'd either use a separate single-purpose overlay or add it to science-overlay. If it's a separate overlay, then googleearth overlay in gentoo's github account for easy access for users, both to get and contribute. This is scope of proxy-main, imho. starting overlays for single pckages is hilarious. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHsbKUACgkQknrdDGLu8JDlZQD/fnk1Z869tY0DUVjSedW/TDnm bVuv0IrCjn/UJoDvjIMBAJCMgLNF2QUBprZMVjw5Fj6zFiWqGckCM+Q0aHBieUJ7 =DH1b -END PGP SIGNATURE-
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 01:20 AM, Michael Weber wrote: On 07/22/2013 01:03 AM, Brian Dolbec wrote: On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote: On 07/22/2013 12:33 AM, Michał Górny wrote: I'd either use a separate single-purpose overlay or add it to science-overlay. If it's a separate overlay, then googleearth overlay in gentoo's github account for easy access for users, both to get and contribute. This is scope of proxy-main, imho. starting overlays for single pckages is hilarious. You are ignoring the rest of the arguments. The main concern is not how people can contribute. And I said more than once that we can probably move it to science-overlay. The only question now is if we want to keep it p.masked or remove it. I don't like pmasking package indefinitely. Afaiu pmasks are rather meant for a) new, very hot versions of libraries/tools that can break your system in more than one part b) security masks, temporary masks and other masks we expect to remove in the future
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 21/07/2013 23:38, hasufell wrote: - consistency of tree quality does not apply to p.mask'd packages p.mask says that the package is in _bad_ quality, explicitly, and you can say how, so does not apply are not really the words I'd use. - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree maybe Not p.masked packages they don't. Just state it outright, maybe even fetch-restrict the package and warn them... - less bugs no one can do anything about does not apply *How* does making it into a semi-official one-purpose overlay reduce the number of bugs users report? Either you're banning it into a non-Gentoo-owned overlay, or you're just betting they would get the reason why it's not in an overlay, same applies to p.mask. - easier contribution of users in an overlay, testing of hacks or other stuff to make it work does not apply I'm afraid I have to agree with Michael here. Proxies would do that, and users are still free to experiment with overlaid version, I don't see how this makes much of a difference. - making clear that gentoo does not support software with such low QA does not apply It applies perfectly. It's a p.mask for a reason, and can convey reasons. It's your package, do what you want, but stop just trying to force your views into suggestions, just because you already reached your conclusion, please. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 6:33 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-07-22, o godz. 00:16:31 hasufell hasuf...@gentoo.org napisał(a): - users have to run layman -a foo ...I hope they will manage (and the masking reason will be updated to explain where to look for googleearth ebuilds) Then to get *a single package* they start using the whole overlay. If it's a sane overlay, fine. But some overlays really replace a lot of stuff silently and trigger failures we didn't even imagine before. We're starting to drift off topic here, but I've always felt that this is something that could be improved on. I'm not saying that any of this should just be thrown together, but some of the following might be useful: 1. Overlay dependencies (depends on a particular package from a particular overlay). 2. Overlay package.* (accept one version of one package from a particular overlay, mask all packages in an overlay that aren't explicitly unmasked, don't apply package.(un)mask from one overlay to packages in another unless the mask references that overlay specifically, etc). 3. Repository priority (paludis handles this fairly well I think) - where you can control which overlays override which other ones. I've never really liked the all-or-nothing design of overlays as they currently stand. Even simply prioritizing them is a pretty crude approach. It makes them fairly useless for general-purpose distribution of packages. Rich
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 01:49 AM, Diego Elio Pettenò wrote: On 21/07/2013 23:38, hasufell wrote: - consistency of tree quality does not apply to p.mask'd packages p.mask says that the package is in _bad_ quality, explicitly, and you can say how, so does not apply are not really the words I'd use. I did not know that p.mask is used indefinitely for low quality packages and I don't like that concept. - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree maybe Not p.masked packages they don't. Just state it outright, maybe even fetch-restrict the package and warn them... - less bugs no one can do anything about does not apply *How* does making it into a semi-official one-purpose overlay reduce the number of bugs users report? Either you're banning it into a non-Gentoo-owned overlay, or you're just betting they would get the reason why it's not in an overlay, same applies to p.mask. It will reduce the number of bugs, because there will be no bugtracker, but only pull-requests. It would not be hosted on o.g.o. which means gentoo bugs are not allowed. - easier contribution of users in an overlay, testing of hacks or other stuff to make it work does not apply I'm afraid I have to agree with Michael here. Proxies would do that, and users are still free to experiment with overlaid version, I don't see how this makes much of a difference. Well, I actually only mentioned that point as a side effect. Until now... no one was able to provide a patch to fix one of the bugs you can read in a hundred forums and bug trackers. But it wouldn't make much of a difference, that's probably true. - making clear that gentoo does not support software with such low QA does not apply It applies perfectly. It's a p.mask for a reason, and can convey reasons. It does not apply, because we still support it officially in our main tree as a distribution, no matter if it's p.masked or not. One could probably argue that no one cares about this difference, but it's still true. Anyway... if people disagree, then it doesn't make much sense to remove it. Otherwise it will pop up in the tree sooner or later again.
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 5:34 PM, Rich Freeman ri...@gentoo.org wrote: We're starting to drift off topic here, but I've always felt that this is something that could be improved on. I'm not saying that any of this should just be thrown together, but some of the following might be useful: 1. Overlay dependencies (depends on a particular package from a particular overlay). In EAPI 5-progress, there's support for atom::repo deps. 2. Overlay package.* (accept one version of one package from a particular overlay, mask all packages in an overlay that aren't explicitly unmasked, don't apply package.(un)mask from one overlay to packages in another unless the mask references that overlay specifically, etc). These things are all supported by portage, through use of atom::repo in /etc/portage/package.* (or profile with EAPI 5-progress) and repo-level configurations in $repo/profiles/package.* (which only apply to packages from that repo). 3. Repository priority (paludis handles this fairly well I think) - where you can control which overlays override which other ones. Portage also supports priority setting in /etc/portage/repos.conf. I've never really liked the all-or-nothing design of overlays as they currently stand. These days, they should be much more flexible than they have been in the past. Even simply prioritizing them is a pretty crude approach. It makes them fairly useless for general-purpose distribution of packages. Rich
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/22/2013 02:34 AM, Rich Freeman wrote: 2. Overlay package.* (accept one version of one package from a particular overlay, mask all packages in an overlay that aren't explicitly unmasked, don't apply package.(un)mask from one overlay to packages in another unless the mask references that overlay specifically, etc). Inside /etc/portage, */*::xmw is a valid token for p.mask, p.keyword etc. p.mask:*/*::xmw p.unmask:virtual/xmwce::xmw works. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHsx+sACgkQknrdDGLu8JD+uQD9E3iEX8p3zAC2Isbb8r1SJfWr xUSK7P3F3Q3iFajBhXIA/0r2F4qyhidkjqGD8aUlJ+o+vcReCmBXegsEGbDUL496 =2xcw -END PGP SIGNATURE-
