[gentoo-dev] remove sci-geosciences/googleearth from the tree

[gentoo-dev] remove sci-geosciences/googleearth from the tree

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am maintaining it for some months now and it has reached a state
where we should think about treecleaning it.

reasons:
a) bundles tons of libs since ages (security and stability issues,
many of them can not be unbundled)
https://bugs.gentoo.org/show_bug.cgi?id=212373
b) segfaults randomly; the new version as well
https://code.google.com/p/earth-api-samples/issues/detail?id=957
https://code.google.com/p/earth-issues/issues/detail?id=1608
https://bugs.gentoo.org/show_bug.cgi?id=470684
c) random runtime bugs
https://bugs.gentoo.org/show_bug.cgi?id=474462
d) upstream ignores bug reports or is unable to fix them
e) upstream is unable to upload tarballs with a version in the
filename which leads to checksum failure and trouble for users if they
want to install an older version, because the new one is broken again

Maintaining a package in gentoo implies a few things for me:
We are able to support it properly which either means that we can
communicate with upstream or at least (if that fails) fix bugs on our
own. Currently, both does not apply to googleearth which means we
cannot resolve a lot of bugs in any way.
Also... software in the tree should meet a minimum of quality and we
should not support vulnerable and broken software officially.

solution: Treeclean it and maintain it in an overlay (maybe
science-overlay). That's exactly what overlays are for... experimental
stuff.

alternatives to googleearth:
- - lots of web services ("google maps", "openstreet maps", ...)
- - "nasa world wind" (not in the tree afais but opensource and java)
- - kde-base/marble
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR6/ywAAoJEFpvPKfnPDWzHjMIAKqEUw5AKmuSxLe8hicFDqbN
lR92Hq6cKMqhJDrIB/uohT+PdjnBfC4hZabCFLPSB9uijOXpR2cliwFeKuq6eeJE
3HW1UuaVd71s0r8cCGO6sFhuoN56DJapF0OvU6TU7CouZcpR7gIuN7jhGcj4uVf2
JDI8HT+n4f9L5cTSb65YhLYZjuUGEHqZn6g6X6o2G01kZaoYPyFHatUkfXyb7FSm
jpJWCLWv4CdmEZWb+YbN+afHGYU4rkbW7XLJ6gLmvJxx/TtHg9FFU6xJotAlMvTL
X5lHQDep2iWwYm7hA5r1h9xM98ElucI4Eg+lsiLbkmCj3mIR3QS5Nq+b2VaN9lc=
=Qslh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] remove sci-geosciences/googleearth from the tree

[Rich Freeman]

On Sun, Jul 21, 2013 at 11:22 AM, hasufell <hasufell@gentoo.org> wrote:
> I am maintaining it for some months now and it has reached a state
> where we should think about treecleaning it.

++

> Maintaining a package in gentoo implies a few things for me:
> We are able to support it properly which either means that we can
> communicate with upstream or at least (if that fails) fix bugs on our
> own. Currently, both does not apply to googleearth which means we
> cannot resolve a lot of bugs in any way.
> Also... software in the tree should meet a minimum of quality and we
> should not support vulnerable and broken software officially.

From your description it seems like Google Earth is really pushing it.
 I wouldn't call it "vulnerable" and "broken" though - software is
only vulnerable if there is a known exploit.  Bundling libraries is
bad practice because it increases the risk of such vulnerabilities
existing, but on its own shouldn't be grounds for removal.  It
certainly has the potential to increase the workload for maintainers
though.

My sense is that none of the problems you listed should really be
considered a reason that something MUST be removed from the tree, but
they certainly tend to add up.  If somebody wants to take over
wrestling with it I don't think we should look down on that though.

Rich

Re: [gentoo-dev] remove sci-geosciences/googleearth from the tree

[hasufell]

On 07/21/2013 07:42 PM, Rich Freeman wrote:
> On Sun, Jul 21, 2013 at 11:22 AM, hasufell <hasufell@gentoo.org> wrote:
>> I am maintaining it for some months now and it has reached a state
>> where we should think about treecleaning it.
> 
> ++
> 
>> Maintaining a package in gentoo implies a few things for me:
>> We are able to support it properly which either means that we can
>> communicate with upstream or at least (if that fails) fix bugs on our
>> own. Currently, both does not apply to googleearth which means we
>> cannot resolve a lot of bugs in any way.
>> Also... software in the tree should meet a minimum of quality and we
>> should not support vulnerable and broken software officially.
> 
> From your description it seems like Google Earth is really pushing it.
>  I wouldn't call it "vulnerable" and "broken" though - software is
> only vulnerable if there is a known exploit.  Bundling libraries is
> bad practice because it increases the risk of such vulnerabilities
> existing, but on its own shouldn't be grounds for removal.  It
> certainly has the potential to increase the workload for maintainers
> though.
> 
> My sense is that none of the problems you listed should really be
> considered a reason that something MUST be removed from the tree, but
> they certainly tend to add up.  If somebody wants to take over
> wrestling with it I don't think we should look down on that though.
> 
> Rich
> 

I have no problem with maintaing it, but that does not change my opinion
that it's simply not fit for the tree.

I'd maintain it in an overlay then where we can play with hacks and
whatnot to get it working.

But people should expect that things work somehow in the tree, even on
~arch. Even worse: the stable googleearth builds are unfetchable and
that's not how I'd define any stable ebuild in the tree.

Re: [gentoo-dev] remove sci-geosciences/googleearth from the tree

[Rich Freeman]

On Sun, Jul 21, 2013 at 1:55 PM, hasufell <hasufell@gentoo.org> wrote:
> But people should expect that things work somehow in the tree, even on
> ~arch. Even worse: the stable googleearth builds are unfetchable and
> that's not how I'd define any stable ebuild in the tree.

You'll get no argument from me on any of that.  At the very least
something like this probably needs to be repackaged and hosted,
assuming this is legally permissible.

Rich

[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Duncan]

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

[hasufell]

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

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Sun, Jul 21, 2013 at 11:16 PM, hasufell <hasufell@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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[-- Attachment #2: Type: text/html, Size: 1296 bytes --]

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

Dnia 2013-07-22, o godz. 00:16:31
hasufell <hasufell@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[hasufell]

-----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 <hasufell@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

[hasufell]

On 07/22/2013 12:22 AM, Diego Elio Pettenò wrote:
> On Sun, Jul 21, 2013 at 11:16 PM, hasufell <hasufell@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

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

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 <hasufell@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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Michael Weber]

-----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 <xmw@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

[hasufell]

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

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Rich Freeman]

On Sun, Jul 21, 2013 at 6:33 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-07-22, o godz. 00:16:31
> hasufell <hasufell@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

[hasufell]

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

[Zac Medico]

On Sun, Jul 21, 2013 at 5:34 PM, Rich Freeman <rich0@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

[Michael Weber]

-----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 <xmw@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-----

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Mon, 22 Jul 2013 01:26:25 +0200
hasufell <hasufell@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Duncan]

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