[gentoo-dev] Sets vs Meta ebuilds

[gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

I have been playing with some package sets and I like the concept of
sets quite a lot. However there is one big drawback. You cannot use a
package set in a profile. Or at least I do not think you can. I have
looked into it a bit and does not seem like it is possible.

I know I can create a meta ebuild and use it like a package set. I
think it would be useful to have package sets be able to be used in a
profile like meta ebuilds. It would likely reduce the need or use of
meta packages. Not sure if there is any benefit to that approach over a
set.

I think sets have benefits over meta packages. This was the most
comprehensive document on sets, benefits, uses, etc. Other than the
general docs on the wiki.
https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/

I  would really like to be able to use package sets in profiles. I
think of use and benefit to others as well.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Lucas Ramage]

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

Is that your blog?

On Fri, Jul 7, 2017 at 12:32 PM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

> I have been playing with some package sets and I like the concept of
> sets quite a lot. However there is one big drawback. You cannot use a
> package set in a profile. Or at least I do not think you can. I have
> looked into it a bit and does not seem like it is possible.
>
> I know I can create a meta ebuild and use it like a package set. I
> think it would be useful to have package sets be able to be used in a
> profile like meta ebuilds. It would likely reduce the need or use of
> meta packages. Not sure if there is any benefit to that approach over a
> set.
>
> I think sets have benefits over meta packages. This was the most
> comprehensive document on sets, benefits, uses, etc. Other than the
> general docs on the wiki.
> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>
> I  would really like to be able to use package sets in profiles. I
> think of use and benefit to others as well.
>
> --
> William L. Thomson Jr.
>



-- 

Regards,

[image: View my Portfolio] <https://lramage94.github.io>

Lucas Ramage / Software Engineer
ramage.lucas94@gmail.com / (941)-467-2354

Visit online journal
lramage94.github.io

[image: Google Plus]  <https://plus.google.com/+LucasRamage>[image:
Linkedin] <https://www.linkedin.com/pub/lucas-ramage/4a/719/757>

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Fri, 7 Jul 2017 12:36:16 -0400
Lucas Ramage <ramage.lucas94@gmail.com> wrote:

> Is that your blog?

No it is not my blog. I do not have a blog. I have no idea about the
blog owner/author. Google brought me there via some search. Not sure it
was even regarding sets as I had no idea about them till I came across
that blog post. But sets seem pretty nifty. I liked them till I tried
using one in a profile.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 2097 bytes --]

On 07/07/2017 12:32 PM, William L. Thomson Jr. wrote:
> I have been playing with some package sets and I like the concept of
> sets quite a lot. However there is one big drawback. You cannot use a
> package set in a profile. Or at least I do not think you can. I have
> looked into it a bit and does not seem like it is possible.
> 
> I know I can create a meta ebuild and use it like a package set. I
> think it would be useful to have package sets be able to be used in a
> profile like meta ebuilds. It would likely reduce the need or use of
> meta packages. Not sure if there is any benefit to that approach over a
> set.
> 
> I think sets have benefits over meta packages. This was the most
> comprehensive document on sets, benefits, uses, etc. Other than the
> general docs on the wiki.
> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
> 
> I  would really like to be able to use package sets in profiles. I
> think of use and benefit to others as well.
> 

There is actually a huge functional difference between the two that you
are missing here.  A meta package defines its dependencies in full
dependency syntax.  This means you can specify versions, USE flag
dependencies, make packages dependent on USE flags, etc.  A package set
is just a list of packages (potentially constrained by version.  TTBOMK,
there is no inclusion of any USE flag functionality in sets.
Additionally, let's say you have a more complicated dependency like || (
A B ),  I don't think there is a way to describe that in a package set
at all.

I'm not sure I see the merit in pushing for package sets in the bulk of
cases for this reason.  Maybe there is some scenario where package sets
are a better option, but you haven't enumerated what that might be (and
I'm not really interested in brainstorming until I come up with one, so
I'll wait for one frmo someone else)

Of course, my sets knowledge is a little limited compared to some
people, so if something I've said about package sets is incorrect,
please feel free to correct it.

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Fri, 7 Jul 2017 12:48:04 -0400
NP-Hardass <NP-Hardass@gentoo.org> wrote:
> 
> There is actually a huge functional difference between the two that
> you are missing here.  A meta package defines its dependencies in full
> dependency syntax.  This means you can specify versions, USE flag
> dependencies, make packages dependent on USE flags, etc.  A package
> set is just a list of packages (potentially constrained by version.
> TTBOMK, there is no inclusion of any USE flag functionality in sets.
> Additionally, let's say you have a more complicated dependency like
> || ( A B ),  I don't think there is a way to describe that in a
> package set at all.

All valid points, but there maybe times when such is not needed.

You cannot really do any of that easily via a profile either. You just
have packages file in a profile. You can use the other stuff, but I am
talking about sets. Just as packages are listed in a packages file in a
profile. Being able to list a package set, vs those same packages.
There is no difference there.

> I'm not sure I see the merit in pushing for package sets in the bulk
> of cases for this reason.  Maybe there is some scenario where package
> sets are a better option, but you haven't enumerated what that might
> be (and I'm not really interested in brainstorming until I come up
> with one, so I'll wait for one frmo someone else)

Not sure I need to show a case example of where sets are better than
meta packages. Its more I want to use sets and I would like to be able
to include those package sets in a profile.
 
> Of course, my sets knowledge is a little limited compared to some
> people, so if something I've said about package sets is incorrect,
> please feel free to correct it.

You cannot remove all packages ( short of dep clean ) or re-emerge all
packages from a meta ebuild easily. You can from a set.

Sets do have their uses. I think they are not used much for a variety
of reasons, but likely could be used more.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 3336 bytes --]

On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> There is actually a huge functional difference between the two that
>> you are missing here.  A meta package defines its dependencies in full
>> dependency syntax.  This means you can specify versions, USE flag
>> dependencies, make packages dependent on USE flags, etc.  A package
>> set is just a list of packages (potentially constrained by version.
>> TTBOMK, there is no inclusion of any USE flag functionality in sets.
>> Additionally, let's say you have a more complicated dependency like
>> || ( A B ),  I don't think there is a way to describe that in a
>> package set at all.
> 
> All valid points, but there maybe times when such is not needed.
> 
> You cannot really do any of that easily via a profile either. You just
> have packages file in a profile. You can use the other stuff, but I am
> talking about sets. Just as packages are listed in a packages file in a
> profile. Being able to list a package set, vs those same packages.
> There is no difference there.
> 

Yeah, but I'm not wild about the prospect of handling some packages via
one method, and others via another.  Could you imagine if half of your
@system packages were broken up into subsets, and half were left as is?
The lack of uniformity would unnecessarily complicate things IMO.

>> I'm not sure I see the merit in pushing for package sets in the bulk
>> of cases for this reason.  Maybe there is some scenario where package
>> sets are a better option, but you haven't enumerated what that might
>> be (and I'm not really interested in brainstorming until I come up
>> with one, so I'll wait for one frmo someone else)
> 
> Not sure I need to show a case example of where sets are better than
> meta packages. Its more I want to use sets and I would like to be able
> to include those package sets in a profile.
>  

Then why are we in a topic comparing metas and sets? :P  Sounds like the
best thing is to change this whole topic into an RFC for profile-enabled
sets and file a bug report feature requesting it after getting feedback.

>> Of course, my sets knowledge is a little limited compared to some
>> people, so if something I've said about package sets is incorrect,
>> please feel free to correct it.
> 
> You cannot remove all packages ( short of dep clean ) or re-emerge all
> packages from a meta ebuild easily. You can from a set.

This is two-tiered in both cases anyway, no?
Meta:
# Remove meta
emerge --depclean meta
# Remove all packages in the meta and their pulled in deps
emerge --depclean
Set:
# Remove set
emerge --depclean @set
# clean up all deps pulled in from the set
emerge --depclean

> 
> Sets do have their uses. I think they are not used much for a variety
> of reasons, but likely could be used more.
> 

Sure, but when the thread is "Sets vs Metas" it makes it hard to simply
"make a case for using one more than currently" since instead, you are
inviting a comparison argument, which, as I've said, I think fails to
convince.  Like I said, if your goal is simply to propose enabling
further use of sets, let's work on that, rather than get distracted with
a whole separate issue.

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Fri, 7 Jul 2017 13:31:52 -0400
NP-Hardass <NP-Hardass@gentoo.org> wrote:

> On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> > On Fri, 7 Jul 2017 12:48:04 -0400
> > NP-Hardass <NP-Hardass@gentoo.org> wrote:  
> >>
> Yeah, but I'm not wild about the prospect of handling some packages
> via one method, and others via another.  Could you imagine if half of
> your @system packages were broken up into subsets, and half were left
> as is? The lack of uniformity would unnecessarily complicate things
> IMO.

This is meant to be used at higher levels. Say you want a set of Gnome
packages on KDE, as an example. Or some set of packages of your own.

> Then why are we in a topic comparing metas and sets? :P  Sounds like
> the best thing is to change this whole topic into an RFC for
> profile-enabled sets and file a bug report feature requesting it
> after getting feedback.

Because they each have their use. But seems sets may be under-used.
This topic is more of a RFC and I may file a bug/feature request after.
Granted the topic/process might not have been ideal, but doing just
what you mentioned.
 
> This is two-tiered in both cases anyway, no?

No

> Meta:
> # Remove meta
> emerge --depclean meta
> # Remove all packages in the meta and their pulled in deps
> emerge --depclean
> Set:
> # Remove set
> emerge --depclean @set

That removes the set and any packages brought in, not just the set
packages. You do not need the --depclean to remove a package set.

> # clean up all deps pulled in from the set
> emerge --depclean

Same thing as previous command. Adding --depclean to sets gives you
that. As there is no deps on a set that are not in that set.

Either way you cannot re-emerge packages in a meta. Like rebuilding all
of those. At least not easily to my knowledge.

> > 
> > Sets do have their uses. I think they are not used much for a
> > variety of reasons, but likely could be used more.
> >   
> 
> Sure, but when the thread is "Sets vs Metas" it makes it hard to
> simply "make a case for using one more than currently" since instead,
> you are inviting a comparison argument, which, as I've said, I think
> fails to convince.  Like I said, if your goal is simply to propose
> enabling further use of sets, let's work on that, rather than get
> distracted with a whole separate issue.

They should be compared. Given their differences there is a time and
place to use either. Creating a profile for select packages is
overkill. I think even a meta package of the same is also over kill.
Which does not give you all the same abilities.

I see sets as being very useful in profiles. Meta packages not so much.
That depends on the profile and packages. I see lots of uses for sets
and little use of meta packages. My use of meta packages would be to
get around limitations of ability to use sets. Which is not ideal IMHO.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[James Le Cuirot]

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

On Fri, 7 Jul 2017 12:48:04 -0400
NP-Hardass <NP-Hardass@gentoo.org> wrote:

> There is actually a huge functional difference between the two that you
> are missing here.  A meta package defines its dependencies in full
> dependency syntax.  This means you can specify versions, USE flag
> dependencies, make packages dependent on USE flags, etc.  A package set
> is just a list of packages (potentially constrained by version.  TTBOMK,
> there is no inclusion of any USE flag functionality in sets.
> Additionally, let's say you have a more complicated dependency like || (
> A B ),  I don't think there is a way to describe that in a package set
> at all.

Actually you can specify basic USE dependencies in sets. You can also
specify SLOTs. For example, this is valid.

media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx]

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 972 bytes --]

On 07/07/2017 04:38 PM, James Le Cuirot wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass <NP-Hardass@gentoo.org> wrote:
> 
>> There is actually a huge functional difference between the two that you
>> are missing here.  A meta package defines its dependencies in full
>> dependency syntax.  This means you can specify versions, USE flag
>> dependencies, make packages dependent on USE flags, etc.  A package set
>> is just a list of packages (potentially constrained by version.  TTBOMK,
>> there is no inclusion of any USE flag functionality in sets.
>> Additionally, let's say you have a more complicated dependency like || (
>> A B ),  I don't think there is a way to describe that in a package set
>> at all.
> 
> Actually you can specify basic USE dependencies in sets. You can also
> specify SLOTs. For example, this is valid.
> 
> media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx]
> 

Didn't realize that.  Good to know.

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Fri, 7 Jul 2017 21:38:31 +0100
James Le Cuirot <chewi@gentoo.org> wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass <NP-Hardass@gentoo.org> wrote:
> > There is actually a huge functional difference between the two that
> > you are missing here.  A meta package defines its dependencies in
> > full dependency syntax.  This means you can specify versions, USE
> > flag dependencies, make packages dependent on USE flags, etc.  A
> > package set is just a list of packages (potentially constrained by
> > version.  TTBOMK, there is no inclusion of any USE flag
> > functionality in sets. Additionally, let's say you have a more
> > complicated dependency like || ( A B ),  I don't think there is a
> > way to describe that in a package set at all.  
> 
> Actually you can specify basic USE dependencies in sets. You can also
> specify SLOTs. For example, this is valid.
> 
> media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx]

And this is one of many reasons "sets in profiles" isn't going to work:
we don't really know what most of this stuff means...

-- 
Ciaran McCreesh

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Fri, 7 Jul 2017 21:43:14 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 7 Jul 2017 21:38:31 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> > On Fri, 7 Jul 2017 12:48:04 -0400
> > NP-Hardass <NP-Hardass@gentoo.org> wrote:  
> > > There is actually a huge functional difference between the two
> > > that you are missing here.  A meta package defines its
> > > dependencies in full dependency syntax.  This means you can
> > > specify versions, USE flag dependencies, make packages dependent
> > > on USE flags, etc.  A package set is just a list of packages
> > > (potentially constrained by version.  TTBOMK, there is no
> > > inclusion of any USE flag functionality in sets. Additionally,
> > > let's say you have a more complicated dependency like || ( A B
> > > ),  I don't think there is a way to describe that in a package
> > > set at all.    
> > 
> > Actually you can specify basic USE dependencies in sets. You can
> > also specify SLOTs. For example, this is valid.
> > 
> > media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx]  
> 
> And this is one of many reasons "sets in profiles" isn't going to
> work: we don't really know what most of this stuff means...

Just have to avoid using such features if a set is to be used in a
profile. Gentoo developers have control over profiles, and ideally
these sets as well. Short of some user created ones. Thus most issues
of that nature should be easily preventable.

My main interest is in being able to use a package set in a profile.
While retaining that set on its own for rebuild and other purposes.
Someone may want to use said set, but not a given profile using the set.

Having sets being usable in profiles gives you the best of both.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: Sets vs Meta ebuilds

[Michael Palimaka]

On 07/08/2017 02:48 AM, NP-Hardass wrote:
> On 07/07/2017 12:32 PM, William L. Thomson Jr. wrote:
>> I have been playing with some package sets and I like the concept of
>> sets quite a lot. However there is one big drawback. You cannot use a
>> package set in a profile. Or at least I do not think you can. I have
>> looked into it a bit and does not seem like it is possible.
>>
>> I know I can create a meta ebuild and use it like a package set. I
>> think it would be useful to have package sets be able to be used in a
>> profile like meta ebuilds. It would likely reduce the need or use of
>> meta packages. Not sure if there is any benefit to that approach over a
>> set.
>>
>> I think sets have benefits over meta packages. This was the most
>> comprehensive document on sets, benefits, uses, etc. Other than the
>> general docs on the wiki.
>> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>>
>> I  would really like to be able to use package sets in profiles. I
>> think of use and benefit to others as well.
>>
> 
> There is actually a huge functional difference between the two that you
> are missing here.  A meta package defines its dependencies in full
> dependency syntax.  This means you can specify versions, USE flag
> dependencies, make packages dependent on USE flags, etc.  A package set
> is just a list of packages (potentially constrained by version.  TTBOMK,
> there is no inclusion of any USE flag functionality in sets.
> Additionally, let's say you have a more complicated dependency like || (
> A B ),  I don't think there is a way to describe that in a package set
> at all.

Bug #272488[0] proposed a PROPERTIES="set" feature to combine the power
of sets with the flexibility of ebuilds.

1: https://bugs.gentoo.org/show_bug.cgi?id=272488

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Rich Freeman]

On Fri, Jul 7, 2017 at 10:21 PM, Michael Palimaka <kensington@gentoo.org> wrote:
>
> Bug #272488[0] proposed a PROPERTIES="set" feature to combine the power
> of sets with the flexibility of ebuilds.
>
> 1: https://bugs.gentoo.org/show_bug.cgi?id=272488
>

What do sets get us that packages do not?  Why not move the other
direction and just have packages instead of sets?

One issue I see with sets is that as far as I can tell they aren't
specified in PMS at all, so they can't go into the tree at all, and
not all package managers may support them in the same way.  Certainly
this could be standardized, but I'm not sure what they actually get
us.

-- 
Rich

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 18:34:55 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> 
> What do sets get us that packages do not?  Why not move the other
> direction and just have packages instead of sets?

The blog entry I provided a link to I think made the best case example
of usage of sets and their benefits.
https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/

The biggest advantage is ability to re-emerge all without additional
steps or arguments. Simple emerge @my_set just like emerge world, etc.
Even more useful you can remove a set directly, without depclean.

If you remove a meta package, you have to run depclean to remove the
actual packages in the meta ebuild. Sets save you from this step.

Sets are also used for package rebuilds, like x11-module-rebuild,
live-rebuild, and others.

> One issue I see with sets is that as far as I can tell they aren't
> specified in PMS at all, so they can't go into the tree at all, and
> not all package managers may support them in the same way.  Certainly
> this could be standardized, but I'm not sure what they actually get
> us.

world and system are sets we all have. Not sure about PMS. It is
something portage has supported for some time. You likely have many
sets already on your system

emerge --list-sets

https://wiki.gentoo.org/wiki/World_set_(Portage)
https://wiki.gentoo.org/wiki/System_set_(Portage)
https://wiki.gentoo.org/wiki//etc/portage/sets
https://dev.gentoo.org/~zmedico/portage/doc/ch02s02.html

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Rich Freeman]

On Sat, Jul 8, 2017 at 7:09 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Sat, 8 Jul 2017 18:34:55 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>>
>> What do sets get us that packages do not?  Why not move the other
>> direction and just have packages instead of sets?
>
> The blog entry I provided a link to I think made the best case example
> of usage of sets and their benefits.
> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>
> The biggest advantage is ability to re-emerge all without additional
> steps or arguments. Simple emerge @my_set just like emerge world, etc.
> Even more useful you can remove a set directly, without depclean.

I don't see why a package manager couldn't offer the same
functionality for a meta package.  As was pointed out the set behavior
for unmerging isn't always desirable.

>
> world and system are sets we all have. Not sure about PMS. It is
> something portage has supported for some time. You likely have many
> sets already on your system

Certainly.  You just can't depend on them and so on without having
them in PMS, because portage isn't the only package manager we
"support."

It just strikes me that we're probably better off picking one way of
doing this and putting lots of support behind it, versus having two
ways of doing this and some features work with one but not the other.
Of the two meta packages seem like they're the most generic.

-- 
Rich

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 19:24:46 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> 
> I don't see why a package manager couldn't offer the same
> functionality for a meta package.  As was pointed out the set behavior
> for unmerging isn't always desirable.

Your missing that sets maybe made by the user, Making a meta ebuild is
a bit more complex then dropping package names into a file for a set,
no digest, etc. Sets seem to serve a different purpose.

With regard to unmerging not being desirable. That is if someone does
something stupid like putting a system package into a set. But as I
mentioned that the package is part of another set, system or world. It
would be pulled back into the system.

There are warnings and other stuff that take place when a critical
package is removed. A user can remove those now just as they could if
they added it to a set. Which really makes that argument moot.

Do dumb stuff, you will get undesired results. Like removing a system
package, via any means, set, directly, meta dep, etc.

> >
> > world and system are sets we all have. Not sure about PMS. It is
> > something portage has supported for some time. You likely have many
> > sets already on your system  
> 
> Certainly.  You just can't depend on them and so on without having
> them in PMS, because portage isn't the only package manager we
> "support."

Not sure about other package managers, but I would think they have
similar function. If not then anything listed under emerge --list-sets,
would be portage specific. That would likely break other things.

> It just strikes me that we're probably better off picking one way of
> doing this and putting lots of support behind it, versus having two
> ways of doing this and some features work with one but not the other.
> Of the two meta packages seem like they're the most generic.

The two ways are not the same, and there is a reason sets exist in the
first place. People seem to be over looking that fact. I did not add
sets. They are not new.  I am simply trying to expand their use.

If someone wants to "try" out some packages a set is an ideal way of
doing such. If someone wants a subset of what is in a meta ebuild.
Again a set is an ideal way to do that.  If for no other reason, then
if the user wants to remove them. They just emerge -C @my_set.

I find sets very useful! Only limitation is the profile aspect.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Ciaran McCreesh]

On Sat, 8 Jul 2017 19:39:33 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> The two ways are not the same, and there is a reason sets exist in the
> first place. People seem to be over looking that fact. I did not add
> sets. They are not new.  I am simply trying to expand their use.

Sets exist because people keep saying "let's have sets!" without
agreeing on what sets actually are or how they are to be used. Sets
remain half-baked because it turns out they don't make consistent sense
in different contexts when you give them a non-superficial amount of
thought.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sun, 9 Jul 2017 00:49:57 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 8 Jul 2017 19:39:33 -0400
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > The two ways are not the same, and there is a reason sets exist in
> > the first place. People seem to be over looking that fact. I did
> > not add sets. They are not new.  I am simply trying to expand their
> > use.  
> 
> Sets exist because people keep saying "let's have sets!" without
> agreeing on what sets actually are or how they are to be used.

Do they need to agree? Isn't Gentoo about choice? Maybe your use of
sets is different from mine. Is that not acceptable to have choice?

> Sets  remain half-baked because it turns out they don't make
> consistent sense in different contexts when you give them a
> non-superficial amount of thought.

Much of the world is half baked, but we manage despite such. There is
much to be said about over thinking over engineering something.
Few if anything in life is perfect. Many of the things we depend on are
far from perfect. C'est la vie.

This must be a Gentoo thing. Sets have nothing to do with me. Seems they
have been around since ~2009. Someone coded in support for them etc.
Seems some find use for them, and others have objection.

Having been around Gentoo for some time, and just now coming across
sets. I find them quite useful! Just ran into one limitation of them.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Ciaran McCreesh]

On Sat, 8 Jul 2017 19:58:13 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> On Sun, 9 Jul 2017 00:49:57 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Sat, 8 Jul 2017 19:39:33 -0400
> > "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:  
> > > The two ways are not the same, and there is a reason sets exist in
> > > the first place. People seem to be over looking that fact. I did
> > > not add sets. They are not new.  I am simply trying to expand
> > > their use.    
> > 
> > Sets exist because people keep saying "let's have sets!" without
> > agreeing on what sets actually are or how they are to be used.  
> 
> Do they need to agree? Isn't Gentoo about choice? Maybe your use of
> sets is different from mine. Is that not acceptable to have choice?

Well yes, they do need to agree, because otherwise when two different
developers put sets in a profile expecting different effects, then at
least two developers are going to end up confused, disappointed, and
quite probably breaking user systems.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sun, 9 Jul 2017 01:10:11 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 8 Jul 2017 19:58:13 -0400
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > On Sun, 9 Jul 2017 00:49:57 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:  
> > > On Sat, 8 Jul 2017 19:39:33 -0400
> > > "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:    
> > > > The two ways are not the same, and there is a reason sets exist
> > > > in the first place. People seem to be over looking that fact. I
> > > > did not add sets. They are not new.  I am simply trying to
> > > > expand their use.      
> > > 
> > > Sets exist because people keep saying "let's have sets!" without
> > > agreeing on what sets actually are or how they are to be used.    
> > 
> > Do they need to agree? Isn't Gentoo about choice? Maybe your use of
> > sets is different from mine. Is that not acceptable to have
> > choice?  
> 
> Well yes, they do need to agree, because otherwise when two different
> developers put sets in a profile expecting different effects, then at
> least two developers are going to end up confused, disappointed, and
> quite probably breaking user systems.

Valid points, so basically need a set of guidelines or rules for sets
used in profiles. Which should not be that complex, as usage is minimal.
Offhand, likely could be more;

- Sets used in profiles are "lists of packages" for users to
  emerge/re-emerge, and as such should be minimal list only. Similar to
  the contents of a profile/packages, less the * symbol.

 - Sets used in profiles cannot have use expansion, versions or anything
   beyond cat/pkg.

- Sets should not have the same file listed, in that case inherit the
  other set if using overlapping packages or split into smaller

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2667 bytes --]

On 07/08/2017 06:23 PM, William L. Thomson Jr. wrote:
> On Sun, 9 Jul 2017 01:10:11 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
>> On Sat, 8 Jul 2017 19:58:13 -0400
>> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
>>> On Sun, 9 Jul 2017 00:49:57 +0100
>>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:  
>>>> On Sat, 8 Jul 2017 19:39:33 -0400
>>>> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:    
>>>>> The two ways are not the same, and there is a reason sets exist
>>>>> in the first place. People seem to be over looking that fact. I
>>>>> did not add sets. They are not new.  I am simply trying to
>>>>> expand their use.      
>>>>
>>>> Sets exist because people keep saying "let's have sets!" without
>>>> agreeing on what sets actually are or how they are to be used.    
>>>
>>> Do they need to agree? Isn't Gentoo about choice? Maybe your use of
>>> sets is different from mine. Is that not acceptable to have
>>> choice?  
>>
>> Well yes, they do need to agree, because otherwise when two different
>> developers put sets in a profile expecting different effects, then at
>> least two developers are going to end up confused, disappointed, and
>> quite probably breaking user systems.
> 
> Valid points, so basically need a set of guidelines or rules for sets
> used in profiles. Which should not be that complex, as usage is minimal.
> Offhand, likely could be more;
> 
> - Sets used in profiles are "lists of packages" for users to
>   emerge/re-emerge, and as such should be minimal list only. Similar to
>   the contents of a profile/packages, less the * symbol.
> 
>  - Sets used in profiles cannot have use expansion, versions or anything
>    beyond cat/pkg.
This would break some set behavior, at least in Portage. Specifying a
single version (or better, a slot) in a set is less work than adding
lines to p.mask *and* the set file(s), and p.mask doesn't appear to
support "!=cat/pkg-1.0" syntax to mimic the same functionality achieved
by a versioned atom in a set. It also makes sense to put packages you
want in a set instead of a mask. ">=" or "<=" may be adequate if you
only want one slot or version installed, but the entire point of slots
is to allow multiple versions to be installed simultaneously. Versioned
package names in sets achieve this.

> 
> - Sets should not have the same file listed, in that case inherit the
>   other set if using overlapping packages or split into smaller
> 


-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sun, 9 Jul 2017 00:42:46 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> >  - Sets used in profiles cannot have use expansion, versions or
> > anything beyond cat/pkg.  
> This would break some set behavior, at least in Portage. Specifying a
> single version (or better, a slot) in a set is less work than adding
> lines to p.mask *and* the set file(s), and p.mask doesn't appear to
> support "!=cat/pkg-1.0" syntax to mimic the same functionality
> achieved by a versioned atom in a set. It also makes sense to put
> packages you want in a set instead of a mask. ">=" or "<=" may be
> adequate if you only want one slot or version installed, but the
> entire point of slots is to allow multiple versions to be installed
> simultaneously. Versioned package names in sets achieve this.

Valid point, and along those lines to make the rules for sets in
profiles easier.

- Sets in profiles can contain anything that is valid in a
  profile/packages file, less the * symbol.

I think that addresses both versions and slots. The rest, like use
expansion I believe is handled via package.use in profiles and not in
packages.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1642 bytes --]

On 07/09/2017 06:53 AM, William L. Thomson Jr. wrote:
> On Sun, 9 Jul 2017 00:42:46 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
>>>  - Sets used in profiles cannot have use expansion, versions or
>>> anything beyond cat/pkg.  
>> This would break some set behavior, at least in Portage. Specifying a
>> single version (or better, a slot) in a set is less work than adding
>> lines to p.mask *and* the set file(s), and p.mask doesn't appear to
>> support "!=cat/pkg-1.0" syntax to mimic the same functionality
>> achieved by a versioned atom in a set. It also makes sense to put
>> packages you want in a set instead of a mask. ">=" or "<=" may be
>> adequate if you only want one slot or version installed, but the
>> entire point of slots is to allow multiple versions to be installed
>> simultaneously. Versioned package names in sets achieve this.
> 
> Valid point, and along those lines to make the rules for sets in
> profiles easier.
> 
> - Sets in profiles can contain anything that is valid in a
>   profile/packages file, less the * symbol.
> 
> I think that addresses both versions and slots. The rest, like use
> expansion I believe is handled via package.use in profiles and not in
> packages.
> 

Yeah, that could work. As convenient as it is to mix USE flags with
sets, there's a better place to put it and I'm unsure of any situation
that would require more than two lines (one in the set, one in p.use) to
achieve a given USE constraint.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Zac Medico]

On Sat, Jul 8, 2017 at 4:09 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> Sets are also used for package rebuilds, like x11-module-rebuild,
> live-rebuild, and others.

Usually there are better ways to trigger rebuilds. For example, slot
operator dependencies for rebuilds due to subslot changes, and
--newuse for USE changes. For live-rebuild, it would be much nicer to
have a framework that automatically triggers rebuilds when upstream
changes are detected, like smart-live-rebuild. We can add EAPI/PMS
extensions that allow package managers to do what smart-live-rebuild
does.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 16:35:34 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On Sat, Jul 8, 2017 at 4:09 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> > Sets are also used for package rebuilds, like x11-module-rebuild,
> > live-rebuild, and others.  
> 
> Usually there are better ways to trigger rebuilds. 

Those have nothing to do with me, and I am not using sets for rebuild
purposes. Sets in a profile per my interest and topic have nothing to do
with rebuilding. Just pointing out others current usage of sets.

> For example, slot  operator dependencies for rebuilds due to subslot
> changes, and --newuse for USE changes.

Problem is portage does not catch all changes all the time. Many times
I will update world with binaries, Just to find out if I run without
binaries more packages need to be updated. 

However if there are no changes, and the user wants to rebuild. How do
they do that? Sets make it very easy.

> For live-rebuild, it would be
> much nicer to have a framework that automatically triggers rebuilds
> when upstream changes are detected, like smart-live-rebuild. 

Which would require some sort of check to upstream to detect changes on
some interval. If the user wants to do that manually. How do they do
that? Sets make it very easy.

> We can add EAPI/PMS extensions that allow package managers to do what
> smart-live-rebuild does.

Will that allow a user to rebuild on demand for their own reasons with
no changes to system that are "detectable"?

Again rebuilding is not my interest in sets. That is others usage of
such. However they seem like they could serve a purpose in such
situations. Giving the user really fine grain control without having to
list a set of packages or mess with making various meta ebuilds.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Zac Medico]

On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Sat, 8 Jul 2017 16:35:34 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>
>> For live-rebuild, it would be
>> much nicer to have a framework that automatically triggers rebuilds
>> when upstream changes are detected, like smart-live-rebuild.
>
> Which would require some sort of check to upstream to detect changes on
> some interval.

What I imagine is an option like --newuse that rebuilds packages with
upstream changes. I suppose you could also have an option to rebuild
if some interval has expired since the last rebuild.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 18:30:10 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> > On Sat, 8 Jul 2017 16:35:34 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> >  
> >> For live-rebuild, it would be
> >> much nicer to have a framework that automatically triggers rebuilds
> >> when upstream changes are detected, like smart-live-rebuild.  
> >
> > Which would require some sort of check to upstream to detect
> > changes on some interval.  
> 
> What I imagine is an option like --newuse that rebuilds packages with
> upstream changes. I suppose you could also have an option to rebuild
> if some interval has expired since the last rebuild.

That could be useful for all live packages without requiring a set. It
could also be used for packages that are part of a set. Like if  you
have a set of live ebuilds, plus some others one your system

emerge --live world

Updates all live ebuilds, in a set or not. That would be useful. I tend
to avoid emerging live ebuilds due to having to always re-emerge them.
Sets would help there. But a emerge option would be even better!!!

Could have cron run that, and then an interval in portage is not
necessary. I was more thinking some sort of hook to upstream to see if
there have been any commits or changes. No reason to rebuild a live
package if nothing changed :)

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[Zac Medico]

On Sat, Jul 8, 2017 at 6:39 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Sat, 8 Jul 2017 18:30:10 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>
>> On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr.
>> <wlt-ml@o-sinc.com> wrote:
>> > On Sat, 8 Jul 2017 16:35:34 -0700
>> > Zac Medico <zmedico@gentoo.org> wrote:
>> >
>> >> For live-rebuild, it would be
>> >> much nicer to have a framework that automatically triggers rebuilds
>> >> when upstream changes are detected, like smart-live-rebuild.
>> >
>> > Which would require some sort of check to upstream to detect
>> > changes on some interval.
>>
>> What I imagine is an option like --newuse that rebuilds packages with
>> upstream changes. I suppose you could also have an option to rebuild
>> if some interval has expired since the last rebuild.
>
> That could be useful for all live packages without requiring a set. It
> could also be used for packages that are part of a set. Like if  you
> have a set of live ebuilds, plus some others one your system
>
> emerge --live world
>
> Updates all live ebuilds, in a set or not. That would be useful. I tend
> to avoid emerging live ebuilds due to having to always re-emerge them.
> Sets would help there. But a emerge option would be even better!!!

Yeah, but it's not going to happen without an EAPI/PMS extension.
There needs to be a standard way for the package manager to check if
there has been an upstream change for a given package since the last
time it was rebuilt.

> Could have cron run that, and then an interval in portage is not
> necessary.

Doing updates via cron is inappropriate for most scenarios. I was
thinking that we'd have an option to rebuild if an interval has
expired *and* there has been an upstream change. That way, you can
limit the rate of rebuilds if upstream is changing very frequently.

> I was more thinking some sort of hook to upstream to see if
> there have been any commits or changes. No reason to rebuild a live
> package if nothing changed :)

Yeah, that's what I was thinking all along. That's why we need an
EAPI/PMS extension, in order to implement behavior like
smart-live-rebuild.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 21:30:06 -0700
Zac Medico <zmedico@gentoo.org> wrote:
>
> Yeah, but it's not going to happen without an EAPI/PMS extension.
> There needs to be a standard way for the package manager to check if
> there has been an upstream change for a given package since the last
> time it was rebuilt.

Something to add to the next version possibly.
 
> > Could have cron run that, and then an interval in portage is not
> > necessary.  
> 
> Doing updates via cron is inappropriate for most scenarios. I was
> thinking that we'd have an option to rebuild if an interval has
> expired *and* there has been an upstream change. That way, you can
> limit the rate of rebuilds if upstream is changing very frequently.

I was thinking of cron like regular system updates. May want to rebuild
it nightly, etc. Interval can be done in a variety of ways. The main
issue is detecting if upstream has changed or not.

> > I was more thinking some sort of hook to upstream to see if
> > there have been any commits or changes. No reason to rebuild a live
> > package if nothing changed :)  
> 
> Yeah, that's what I was thinking all along. That's why we need an
> EAPI/PMS extension, in order to implement behavior like
> smart-live-rebuild.

Hopefully that will be in a future version so such can be added. Up to
PMS authors.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 575 bytes --]

On 7/7/2017 12:32 PM, William L. Thomson Jr. wrote:

> I think sets have benefits over meta packages. This was the most
> comprehensive document on sets, benefits, uses, etc. Other than the
> general docs on the wiki.
> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
> 
> I  would really like to be able to use package sets in profiles. I
> think of use and benefit to others as well.
> 

Beware of sets.. if you put toolchain packages in a set and later do
'emerge --unmerge @custom-set' , emerge will happily destroy your toolchain.

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 682 bytes --]

On 7/7/2017 12:57 PM, Brian Evans wrote:
> On 7/7/2017 12:32 PM, William L. Thomson Jr. wrote:
> 
>> I think sets have benefits over meta packages. This was the most
>> comprehensive document on sets, benefits, uses, etc. Other than the
>> general docs on the wiki.
>> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>>
>> I  would really like to be able to use package sets in profiles. I
>> think of use and benefit to others as well.
>>
> 
> Beware of sets.. if you put toolchain packages in a set and later do
> 'emerge --unmerge @custom-set' , emerge will happily destroy your toolchain.
> 
> Brian
> 

or worse dev-lang/python....

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Fri, 7 Jul 2017 12:57:17 -0400
Brian Evans <grknight@gentoo.org> wrote:

> On 7/7/2017 12:32 PM, William L. Thomson Jr. wrote:
> 
> > I think sets have benefits over meta packages. This was the most
> > comprehensive document on sets, benefits, uses, etc. Other than the
> > general docs on the wiki.
> > https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
> > 
> > I  would really like to be able to use package sets in profiles. I
> > think of use and benefit to others as well.
> >   
> 
> Beware of sets.. if you put toolchain packages in a set and later do
> 'emerge --unmerge @custom-set' , emerge will happily destroy your
> toolchain.

That is not much different than removing a system package directly. If
you do foolish things you will run into such problems. That would be a
self inflicted issue. Likely done out of not knowing what you are doing.

Though I will have to see what happens if a package is listed in more
than one set. I think there is a hierarchy there. Not to mention if it
was removed. I think the world or system set would pull it back in.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

On Fri, Jul 07, 2017 at 01:07:57PM -0400, William L. Thomson Jr. wrote
> On Fri, 7 Jul 2017 12:57:17 -0400
> Brian Evans <grknight@gentoo.org> wrote:
> 
> > Beware of sets.. if you put toolchain packages in a set and later
> > do 'emerge --unmerge @custom-set' , emerge will happily destroy
> > your toolchain.
> 
> That is not much different than removing a system package directly.
> If you do foolish things you will run into such problems. That would
> be a self inflicted issue. Likely done out of not knowing what you
> are doing.

  I build Pale Moon to my own custom specs, as well as a contributed
SSE-only build for older machines.  At one point, I read the list of
necessary stuff to do the build.  I incorporated the following into
/etc/portage/palemoon_build

>=app-arch/zip-2.3
>=dev-lang/perl-5.6
>=dev-lang/python-2.7.3
>=dev-lang/yasm-1.0.1
>=dev-libs/glib-2.24
dev-vcs/git
media-libs/fontconfig
>=media-libs/freetype-2.1.0
media-libs/mesa
=sys-devel/autoconf-2.13
sys-devel/gcc
<=x11-libs/gtk+-3.0
x11-libs/libXt
x11-themes/hicolor-icon-theme

> Though I will have to see what happens if a package is listed in more
> than one set. I think there is a hierarchy there.

  I tried "emerge -pv --unmerge @palemoon_build", and it was ready to
delete all the stuff, including gcc, etc.

> Not to mention if it was removed. I think the world or system set
> would pull it back in.

  Kind of hard to "pull it back in" if gcc or glib or ncurses isn't
present.  This is rather dangerous.  The problem is that, unlike an
ebuild, "emerge --unmerge @set" removes all packages in the set,
regardless of whether they're required by another package or not.

  I deleted /etc/portage/sets/palemoon_build, and the entry
"@palemoon_build" from /var/lib/portage/world_sets.  It turns out that
all these packages are required anyways.  hicolor-icon-theme was not
required previously, but <RANT> gtk seems to add more and more GNOME
dependencies every time I update my system. </RANT>

  Let's say I try to do this as a meta package.  So in my overlay I
create a category "meta-set" and a file "meta-set/pmbuild-0.ebuild"

EAPI=5
SLOT="0"
KEYWORDS="amd64 x86"
DEPEND="
       >=app-arch/zip-2.3
       >=dev-lang/perl-5.6
       >=dev-lang/python-2.7.3
       >=dev-lang/yasm-1.0.1
       >=dev-libs/glib-2.24
       dev-vcs/git
       media-libs/fontconfig
       >=media-libs/freetype-2.1.0
       media-libs/mesa
       =sys-devel/autoconf-2.13
       sys-devel/gcc
       <=x11-libs/gtk+-3.0
       x11-libs/libXt
       x11-themes/hicolor-icon-theme"

  Does each entry have to be detailed with configure, install, etc,
stuff, or is this sufficient?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Sat, Jul 8, 2017 at 8:27 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>
>   Let's say I try to do this as a meta package.  So in my overlay I
> create a category "meta-set" and a file "meta-set/pmbuild-0.ebuild"
>
> EAPI=5
> SLOT="0"
> KEYWORDS="amd64 x86"
> DEPEND="
>        >=app-arch/zip-2.3
>        >=dev-lang/perl-5.6
>        >=dev-lang/python-2.7.3
>        >=dev-lang/yasm-1.0.1
>        >=dev-libs/glib-2.24
>        dev-vcs/git
>        media-libs/fontconfig
>        >=media-libs/freetype-2.1.0
>        media-libs/mesa
>        =sys-devel/autoconf-2.13
>        sys-devel/gcc
>        <=x11-libs/gtk+-3.0
>        x11-libs/libXt
>        x11-themes/hicolor-icon-theme"
>
>   Does each entry have to be detailed with configure, install, etc,
> stuff, or is this sufficient?
>

Setting aside QA stuff like description/etc (which wouldn't matter if
you're just doing this in your own overlay) this should work fine.  If
you install this it would pull in all the other stuff, and then do
nothing.  If you intend for this stuff to stick around you probably
want to put it in RDEPEND, otherwise it will just get cleaned at first
opportunity.

Ebuilds specify their dependencies, they don't have to replicate the
ebuilds of those dependencies.  If portage needs to install git it
will go read the git ebuild and figure out how to install it.

Most of the stuff under /usr/portage/virtual should give you a sense
of what can be done.  Virtuals are really only different from
meta-packages in how they're used, not how they work.

It is slightly more cruft than a set, but honestly not a great deal so.

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

On Sat, Jul 08, 2017 at 09:29:42PM -0400, Rich Freeman wrote

> It is slightly more cruft than a set, but honestly not a great deal so.

  The only problem is that you have to maintain ebuilds in an overlay
and run "repoman manifest" every time you create or edit a meta package.
Here's an off-the-wall idea to combine the best of both worlds...

* create virtual/rdepend.ebuild in the overlay
* can it inherit/include an RDEPEND list from a specific text file?  E.g.
  /etc/portage/package_rdepend
* "emerge rdepend" after adding items to /etc/portage/package_rdepend
* "emerge --depclean" after deleting from /etc/portage/package_rdepend

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 20:27:38 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
> > Though I will have to see what happens if a package is listed in
> > more than one set. I think there is a hierarchy there.  
> 
>   I tried "emerge -pv --unmerge @palemoon_build", and it was ready to
> delete all the stuff, including gcc, etc.

Did you get any warnings? Your about to remove a system package, etc.
 
> > Not to mention if it was removed. I think the world or system set
> > would pull it back in.  
> 
>   Kind of hard to "pull it back in" if gcc or glib or ncurses isn't
> present.  This is rather dangerous.  The problem is that, unlike an
> ebuild, "emerge --unmerge @set" removes all packages in the set,
> regardless of whether they're required by another package or not.

It is the same as doing emerge -C gcc. At the same time if you built and
generated a binary package. On re-emerge you could pull in the gcc
binary you made when it was installed the first time. I love binary
packages, I make and use them all the time. Invaluable for re-emerging.

If you are making sets, adding system packages, and removing those. I
would assume you are doing that as some sort of testing. Which would
want to re-emerge/install those packages. Depending on what your doing
very likely would want to make and use binaries in that process. Surely
if removing system packages :)

>   I deleted /etc/portage/sets/palemoon_build, and the entry
> "@palemoon_build" from /var/lib/portage/world_sets.  It turns out that
> all these packages are required anyways.

Meaning little was removed after you did emerge --depclean world ?

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

On Sat, Jul 08, 2017 at 09:32:09PM -0400, William L. Thomson Jr. wrote
> On Sat, 8 Jul 2017 20:27:38 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> >
> > > Though I will have to see what happens if a package is listed in
> > > more than one set. I think there is a hierarchy there.  
> > 
> >   I tried "emerge -pv --unmerge @palemoon_build", and it was ready to
> > delete all the stuff, including gcc, etc.
> 
> Did you get any warnings? Your about to remove a system package, etc.

  Yes, for gcc.

> If you are making sets, adding system packages, and removing those. I
> would assume you are doing that as some sort of testing. Which would
> want to re-emerge/install those packages. Depending on what your doing
> very likely would want to make and use binaries in that process. Surely
> if removing system packages :)

  Here's the problem... when I need some extra packages for a specific
project, I want them to be pulled in *IF NOT ALREADY PRESENT*.  If/when
I finish the project, I want to remove packages *THAT ARE NOT
DEPENDANCIES FOR OTHER PACKAGES I'M KEEPING*.  Using set terminology, as
in high school math, where
* A is the set of (packages I normally require) 
* B is the set of (requirements for project X)

...I want to end up with ( A union B )

If I ever finish the project and decide to unmerge the meta-set I only
want to unmerge...
( A union B ) - ( A )

  If / when I unmerge the meta-set, I want to only unmerge stuff that is
not part of (packages I normally require).  I do not want all members of
the set unmerged unconditionally, regardless of being dependancies for
packages I still have.

  This is where a meta-package is superior to a set.  I simply unmerge
the meta-package, and "emerge --ask --depclean".  If a meta-set item is
a dependancy of a package that I'll be keeping, it won't get removed.  I
do not want to risk removing a package that is needed elsewhere.  And 2
or 3 years later, I may have installed packages that have members of the
meta-set as a dependancy.  A meta-package removes the risk of shooting
myself in the foot.

> >   I deleted /etc/portage/sets/palemoon_build, and the entry
> > "@palemoon_build" from /var/lib/portage/world_sets.  It turns out
> > that all these packages are required anyways.
> 
> Meaning little was removed after you did emerge --depclean world ?

  Nothing would've been removed.  Several months ago, the hicolor-icon
theme would've been removed.  But it has recently been added to the
ever-growing list of gtk dependancies.  GTK == GNOME Tool Kit,
regardless of what they officially call it.

  I only ran a "pretend" unmerge, to see what would happen if I did
unmerge the set.  As a precaution, I've decided to migrate over to a
meta-package.  As per Rich Freeman's recommendation, I'll go with
RDEPEND, and fill in optional descriptive fields in the meta-set.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sun, 9 Jul 2017 05:24:19 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Sat, Jul 08, 2017 at 09:32:09PM -0400, William L. Thomson Jr. wrote
> > On Sat, 8 Jul 2017 20:27:38 -0400
> > "Walter Dnes" <waltdnes@waltdnes.org> wrote:  
> > >  
> > > > Though I will have to see what happens if a package is listed in
> > > > more than one set. I think there is a hierarchy there.    
> > > 
> > >   I tried "emerge -pv --unmerge @palemoon_build", and it was
> > > ready to delete all the stuff, including gcc, etc.  
> > 
> > Did you get any warnings? Your about to remove a system package,
> > etc.  
> 
>   Yes, for gcc.

Which if someone ignores warnings, and breaks their system, it is on
them. At that point your best to remove said package from the set, and
then proceed with removing the set.

>   If / when I unmerge the meta-set, I want to only unmerge stuff that
> is not part of (packages I normally require).  I do not want all
> members of the set unmerged unconditionally, regardless of being
> dependancies for packages I still have.

That is  a matter of knowing what is in the set and on your system. In
that case the idea for a set would be to add packages that are NOT part
of your normal system. Adding packages part of your system would defeat
the benefit.
 
>   This is where a meta-package is superior to a set.  I simply unmerge
> the meta-package, and "emerge --ask --depclean".  If a meta-set item
> is a dependancy of a package that I'll be keeping, it won't get
> removed.  I do not want to risk removing a package that is needed
> elsewhere.  And 2 or 3 years later, I may have installed packages
> that have members of the meta-set as a dependancy.  A meta-package
> removes the risk of shooting myself in the foot.

Yes in the case you just add stuff into a set, not paying attention if
it is a dep of another package, present or future. Then a meta ebuild
does allow someone to be "lazier" ( not insulting you ) and know less
about their system and packages. Just toss package names into a ebuild,
and not worry if its a dep or not, past, present, or future.

It is a way to go, but others may want more fine grained control and
have more awareness of package dependencies, and only add non dependent
non-system packages to a set.

> > >   I deleted /etc/portage/sets/palemoon_build, and the entry
> > > "@palemoon_build" from /var/lib/portage/world_sets.  It turns out
> > > that all these packages are required anyways.  
> > 
> > Meaning little was removed after you did emerge --depclean world ?  
> 
>   Nothing would've been removed.  Several months ago, the hicolor-icon
> theme would've been removed.  But it has recently been added to the
> ever-growing list of gtk dependancies.  GTK == GNOME Tool Kit,
> regardless of what they officially call it.

More a result of RedHat's involvement in both GTK and Gnome. Also FYI
High Color should be a dep of all desktops, or anything that complies
with freedesktop.org standards.
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout

Its where random application icons are installed that are not bound to
any one theme. /usr/share/icons/hicolor/

If no theme provides an icon, it looks in hicolor and uses that.

>   I only ran a "pretend" unmerge, to see what would happen if I did
> unmerge the set.  As a precaution, I've decided to migrate over to a
> meta-package.  As per Rich Freeman's recommendation, I'll go with
> RDEPEND, and fill in optional descriptive fields in the meta-set.

In your case a meta ebuild is likely a better suited for your needs and
uses. Yes you want RDEPEND, I was going to comment on that but Rich had
already so no need to duplicate. Though technically a meta ebuilds does
not need those to run, just the way to pull them in.


-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

On Sun, Jul 09, 2017 at 09:49:08AM -0400, William L. Thomson Jr. wrote
> On Sun, 9 Jul 2017 05:24:19 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
> >   Yes, for gcc.
> 
> Which if someone ignores warnings, and breaks their system, it is on
> them. At that point your best to remove said package from the set, and
> then proceed with removing the set.

  "Fat-Finger" does happen once in while.  Removing the risk of it
happening in the first place is a lot more robust/bulletproof.

> >   If / when I unmerge the meta-set, I want to only unmerge stuff that
> > is not part of (packages I normally require).  I do not want all
> > members of the set unmerged unconditionally, regardless of being
> > dependancies for packages I still have.
> 
> That is  a matter of knowing what is in the set and on your system. In
> that case the idea for a set would be to add packages that are NOT part
> of your normal system. Adding packages part of your system would defeat
> the benefit.
>  
> >   This is where a meta-package is superior to a set.  I simply unmerge
> > the meta-package, and "emerge --ask --depclean".  If a meta-set item
> > is a dependancy of a package that I'll be keeping, it won't get
> > removed.  I do not want to risk removing a package that is needed
> > elsewhere.  And 2 or 3 years later, I may have installed packages
> > that have members of the meta-set as a dependancy.  A meta-package
> > removes the risk of shooting myself in the foot.
> 
> Yes in the case you just add stuff into a set, not paying attention if
> it is a dep of another package, present or future. Then a meta ebuild
> does allow someone to be "lazier" ( not insulting you ) and know less
> about their system and packages. Just toss package names into a ebuild,
> and not worry if its a dep or not, past, present, or future.

  Everybody who doesn't run LFS (Linux From Scratch) is "lazy" in that
regard.  Figuring out dependancies is the job of a package manager, not
the end-user.  I may be getting old, and my head may be slowly becoming
like that of Captain Picard in STTNG (Star Trek The Next Generation).
I do appreciate being able to decide I want something installed and
telling Portage to "Make it so", and letting it take care of details.

a) I don't want to have to spend time figuring out if an item is or is
not a deep dependancy of a package I currently have.

b) I may install other packages later on which may have items already in
the set as a dependancy.

c) Even if *I* don't change "world", GNOME's ever-growing hard-coded
dependancy list will change.  hicolor-icons is just one example.  I use
ICEWM as my WM, with no DE (see my sig).  But gnumeric is/was a good
spreadsheet that I need.  Over the years, I've seen stuff added to
gnumeric's dependancies like "goffice", "ghostscript", "harfbuzz",
"dbus", etc, etc.  Most of that comes via GTK3.  I wouldn't be surprised
if GTK4 adds pulseaudio and/or systemd as hard-coded dependancies.  I'd
love to see somebody port gnumeric and Pale Moon to use FTLK
( http://www.fltk.org/index.php ) instead of GTK, to get away from that
bloat.  Too bad I'm not a programmer.

> It is a way to go, but others may want more fine grained control and
> have more awareness of package dependencies, and only add non
> dependent non-system packages to a set.

  Assuming it's not a lot of additional work, what exactly do sets allow
that meta packages don't?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sun, 9 Jul 2017 21:37:11 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
>   "Fat-Finger" does happen once in while.  Removing the risk of it
> happening in the first place is a lot more robust/bulletproof.

There is nothing in place to stop you from removing gcc, or other
system packages. Adding such to a set, removing them, then expecting
the system to prevent you from doing that. Really does not make sense.
You are creating the set. You are also ignoring warnings on un-emerge.
That is several mistakes.

Either way, removing gcc as part of a set, or directly, or any other
system package can happen regardless. There is nothing bullet proof.
Nothing to stop you either way, except the warning.
 
>   Everybody who doesn't run LFS (Linux From Scratch) is "lazy" in that
> regard.  Figuring out dependancies is the job of a package manager,
> not the end-user.

Dependencies are really not part of the sets discussion. That came from
something you had mentioned about deps remaining after removing a set.

>  I may be getting old, and my head may be slowly
> becoming like that of Captain Picard in STTNG (Star Trek The Next
> Generation). I do appreciate being able to decide I want something
> installed and telling Portage to "Make it so", and letting it take
> care of details.

Then do so, but if you start creating sets, and doing bad stuff in that
process. Really cannot blame sets.

> a) I don't want to have to spend time figuring out if an item is or is
> not a deep dependancy of a package I currently have.

Packages added to a set are rarely deps of each other, and usually
unrelated packages. It depends on the set, and in this case we are
talking user created set. Which means you are only adding packages you
want to the set. From there portage handles deps like normal. I fail to
see the issue.

> b) I may install other packages later on which may have items already
> in the set as a dependancy.

Then maybe you should avoid using sets. If your not going to pay
attention to what you put in them. Just to remove. But again if its a
dep of another. Assuming your doing things properly and doing a world
update after any package removal. Any deps removed would be brought
back in.

But your missing that you are creating all this yourself. You do not
have to create a set. If you do and remove it. Then you should be
familiar with the package you are putting in the set, and if it is a
dep of other stuff.

Its bad administration to just toss something into a set. For that
package to become a dep of something else on the system. The package
being in the set serves no purpose then.

> c) Even if *I* don't change "world", GNOME's ever-growing hard-coded
> dependancy list will change. 

Then seems like you will need to constantly review the packages you put
into a set and remove any that are brought in by other things. It seems
like for what you are doing sets are not good. For others they maybe,
who are doing things differently.

> > It is a way to go, but others may want more fine grained control and
> > have more awareness of package dependencies, and only add non
> > dependent non-system packages to a set.  
> 
>   Assuming it's not a lot of additional work, what exactly do sets
> allow that meta packages don't?

If you followed the thread. It allows you to directly remove the
packages without having to depclean or remove the packages
individually as a list. Also you can rebuild said packages.  The
rebuilding on demand is likely the biggest feature.

You cannot rebuild a meta package on demand. You can rebuild the meta
package, but not the packages in the meta package. You would have to
list those one by one. Thus using a set is much easier.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 00:43:11 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> On Sun, 9 Jul 2017 21:37:11 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> >
> >   "Fat-Finger" does happen once in while.  Removing the risk of it
> > happening in the first place is a lot more robust/bulletproof.  
> 
> There is nothing in place to stop you from removing gcc, or other
> system packages. Adding such to a set, removing them, then expecting
> the system to prevent you from doing that. Really does not make sense.
> You are creating the set. You are also ignoring warnings on un-emerge.
> That is several mistakes.
> 
> Either way, removing gcc as part of a set, or directly, or any other
> system package can happen regardless. There is nothing bullet proof.
> Nothing to stop you either way, except the warning.

Speaking of removing packages. If you remove a package that is a dep of
another, say a virtual or meta ebuild. You do not get ANY warnings. You
will just break that virtual or meta ebuild.

IF that same package was in a set. If you remove any package that is
part of a set. You will get a warning. If you add the set to your
system sets. It will say your removing  a package part of a set.

I think portage should also warn on removing packages that came in from
another. If you are removing any dependency of another package.


-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 508 bytes --]

On 7/10/2017 2:59 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 00:43:11 -0400
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> I think portage should also warn on removing packages that came in from
> another. If you are removing any dependency of another package.
> 
> 

Portage will refuse to remove a package if it is a dependency, but you
have to change the invocation to be 'emerge -avc <package>'.

Then it will be very verbose if something needs said package.

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 15:07:37 -0400
Brian Evans <grknight@gentoo.org> wrote:

> On 7/10/2017 2:59 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 00:43:11 -0400
> > "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > I think portage should also warn on removing packages that came in
> > from another. If you are removing any dependency of another package.
> > 
> >   
> 
> Portage will refuse to remove a package if it is a dependency, but you
> have to change the invocation to be 'emerge -avc <package>'.
> 
> Then it will be very verbose if something needs said package.

Nope, go try yourself. Remove any dep of another package that is not a
system package. You will not get any warnings but the generic one. It
does not know these are a dep and should not be removed. It is not
saying anything about that.

 These are brought in by 2 packages I have installed,
dev-java/tomcat-server and java-virtuals/servlet-api

# emerge -pC tomcat-servlet-api
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies
   before
 * removing packages.

>>> These are the packages that would be unmerged:

 dev-java/tomcat-servlet-api
    selected: 6.0.53 7.0.77 9.0.0_alpha22
   protected: none
     omitted: none

All selected packages: =dev-java/tomcat-servlet-api-6.0.53
 =dev-java/tomcat-servlet-api-7.0.77
 =dev-java/tomcat-servlet-api-9.0.0_alpha22

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Which I just had as a result of doing that previously

!!! ERROR: No provider is available for servlet-api-2.5
                   Please check your environment.
!!! ERROR: No provider is available for servlet-api-3.0
                   Please check your environment.


-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 15:15:35 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> # emerge -pC tomcat-servlet-api
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean <atom>` to check for reverse dependencies
>    before
>  * removing packages.

Rather than a message like the above. I think portage should generate a
message/warning saying you are removing a package that is not in your
world file. Which means you are removing a package you did not install
directly. Just like if you were to remove a system package.

That way people would know if they are removing something that is a
dependency. 

--
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

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

On Mon, Jul 10, 2017 at 2:25 PM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

> On Mon, 10 Jul 2017 15:15:35 -0400
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
>
> > # emerge -pC tomcat-servlet-api
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean <atom>` to check for reverse dependencies
> >    before
> >  * removing packages.
>
> Rather than a message like the above. I think portage should generate a
> message/warning saying you are removing a package that is not in your
> world file. Which means you are removing a package you did not install
> directly. Just like if you were to remove a system package.
>
> That way people would know if they are removing something that is a
> dependency.
>
> --
> William L. Thomson Jr.
>

 Use -c rather than -C, like grknight suggested, and it will.

-Ben

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 14:28:29 -0500
Ben Kohler <bkohler@gmail.com> wrote:
>
>  Use -c rather than -C, like grknight suggested, and it will.

It does not remove, but does not say why either. Which a user may
likely proceed with using -C, as -c had no effect nor did it say why it
took no action.

# emerge -pc tomcat-servlet-api

Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed:   1779
Packages in world:    194
Packages in system:   257
Required packages:    1779
Number to remove:     0

Even when using -C, you still get a warning. Which should happen for
deps just like it does system/world packages.

# emerge -pC gcc
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies
before
 * removing packages.

>>> These are the packages that would be unmerged:


!!! 'sys-devel/gcc' is part of your system profile.
!!! Unmerging it may be damaging to your system.


 sys-devel/gcc
    selected: 6.3.0
   protected: none
     omitted: none

All selected packages: =sys-devel/gcc-6.3.0

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.



-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

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

On Mon, Jul 10, 2017 at 2:36 PM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

> ...
> Calculating dependencies... done!
> >>> No packages selected for removal by depclean
> >>> To see reverse dependencies, use --verbose
> Packages installed:   1779
> Packages in world:    194
> ...
>
# emerge -pC gcc
>  * This action can remove important packages! In order to be safer, use
>  * `emerge -pv --depclean <atom>` to check for reverse dependencies
> before
>  * removing packages.
>
> ...
>
> You aren't taking the time to read your own emerge output.  Now, both of
these recommend --pretend, but you can use --ask with it, for a safe
unmerge that checks for reverse deps THEN allows you to continue only if
it's safe.

Try "emerge -cav gcc.

-Ben

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 14:39:00 -0500
Ben Kohler <bkohler@gmail.com> wrote:
>
> > You aren't taking the time to read your own emerge output. 

It always says that same generic message. If that is the case, then why
even have that option? Why not default to that all the time? Why did
someone give that option + warning vs preventing it in the first place?

> Now, both of these recommend --pretend, but you can use --ask with
> it, for a safe unmerge that checks for reverse deps THEN allows you
> to continue only if it's safe.

It does not matter. I am showing you with -C it generates a warning on
profile and set packages. It does not generate any sort of warning for
deps or packages no in world.

It is the warnings that should exist.

> Try "emerge -cav gcc.

That shows what its pulled in. But no message saying it will not remove
because it is a dependency.

Again this is about informing the user. Both ways leave the user
wanting.

 - The -c option should say why it will not remove.
 - The -C option should warn like it does with profile packages

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

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

>
>
>  - The -c option should say why it will not remove.
>
>
> --
> William L. Thomson Jr.
>
It does, if you use the --verbose flag.  This is mentioned in your emerge
output a few times.

-Ben

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 14:48:23 -0500
Ben Kohler <bkohler@gmail.com> wrote:

> >
> >
> >  - The -c option should say why it will not remove.
> >
> >
> > --
> > William L. Thomson Jr.
> >
> It does, if you use the --verbose flag.  This is mentioned in your
> emerge output a few times.

It just shows the dep chain, not a reason or warning. I am saying it
just needs a warning. A reason why it did not remove. When not using
versbose/-v

Warning like
"Not removing package A as it is a dependency of another package"

This just shows the dep chain, no reason why. Its left to the user to
interpret, since not removed. Its needed by other stuff. But that is
not said explicitly.

# emerge -cav gcc

Calculating dependencies... done!
  sys-devel/gcc-6.3.0 pulled in by:
    @system requires sys-devel/gcc
    dev-db/mysql-5.6.36 requires >=sys-devel/gcc-3.4.6
    media-libs/libmypaint-1.3.0 requires sys-devel/gcc:*[openmp]
    media-libs/mesa-17.1.2 requires >=sys-devel/gcc-4.6
    net-libs/webkit-gtk-2.4.11-r200 requires >=sys-devel/gcc-4.7
    sys-devel/llvm-4.0.0-r2 requires >=sys-devel/gcc-3.0
    sys-libs/glibc-2.24-r2 requires >=sys-devel/gcc-4.7

>>> No packages selected for removal by depclean
Packages installed:   1779
Packages in world:    194
Packages in system:   257
Required packages:    1779
Number removed:       0


This is worse and just needs a message, warning, as to why it was not
removed.

# emerge -pc gcc

Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed:   1779
Packages in world:    194
Packages in system:   257
Required packages:    1779
Number to remove:     0


Either way, as I stated, if using -C, you get warnings with profiles
and sets, but not with deps. Deps should have a warning as well.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 3:45 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Mon, 10 Jul 2017 14:39:00 -0500
> Ben Kohler <bkohler@gmail.com> wrote:
>>
>> > You aren't taking the time to read your own emerge output.
>
> It always says that same generic message. If that is the case, then why
> even have that option?

The --unmerge option is there to let people shoot themselves in the
feet if they know what they're doing.  Anybody who uses it routinely
is going to get burned by it sooner or later.  It simply is not
intended for day-to-day-use.  I'd be all for renaming it to something
like --unsafe-unmerge and getting rid of the short abbreviation.

--depclean is the option people should be using day-to-day.

There are cases with blocks that portage doesn't handle correctly
where --unmerge is sometimes the simplest way around them.  Fortunate
this is rare these days.

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 15:55:47 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jul 10, 2017 at 3:45 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> > On Mon, 10 Jul 2017 14:39:00 -0500
> > Ben Kohler <bkohler@gmail.com> wrote:  
> >>  
> >> > You aren't taking the time to read your own emerge output.  
> >
> > It always says that same generic message. If that is the case, then
> > why even have that option?  
> 
> The --unmerge option is there to let people shoot themselves in the
> feet if they know what they're doing.

Even then you get a warning for profile and set packages, and not for
dependent packages.

Not sure why anyone would have objection to such a warning like exists
for other things. Or providing more information to the user as to why a
package was not removed, or should not be removed.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:27 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Mon, 10 Jul 2017 15:55:47 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>>
>> The --unmerge option is there to let people shoot themselves in the
>> feet if they know what they're doing.
>
> Not sure why anyone would have objection to such a warning like exists
> for other things.

I don't think I've seen anybody raise such an objection.

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 16:30:07 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jul 10, 2017 at 4:27 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> > On Mon, 10 Jul 2017 15:55:47 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >  
> >>
> >> The --unmerge option is there to let people shoot themselves in the
> >> feet if they know what they're doing.  
> >
> > Not sure why anyone would have objection to such a warning like
> > exists for other things.  
> 
> I don't think I've seen anybody raise such an objection.

Then why are we talking -c vs -C, when BOTH need more output...
If there is no objection, why all the emails on -c vs -C?

Neither using -c nor -C addresses the issues I am mentioning with
either. Yet people keep on about those two things and missing the
actual point. Which you say there is no objection. Maybe there is no
understanding rather than objection.

If people understood, then saying use -c or -C makes no sense. It does
not address the lack of output from either I am talking about.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

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

On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

>
> If people understood, then saying use -c or -C makes no sense. It does
> not address the lack of output from either I am talking about.
>
> --
> William L. Thomson Jr.
>
I really thought I understood you in that you wanted true reverse
dependencies calculated, to check against that, and warn for it.  I think
that you are actually talking about a warning upon forced unmerge of
anything not in /var/lib/portage/world, is that correct?

-Ben

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 17:08:54 -0500
Ben Kohler <bkohler@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> 
> >
> > If people understood, then saying use -c or -C makes no sense. It
> > does not address the lack of output from either I am talking about.
> >
> > --
> > William L. Thomson Jr.
> >
> I really thought I understood you in that you wanted true reverse
> dependencies calculated, to check against that, and warn for it. 

You are correct in that. Which the -c option already does. It just does
not tell you why it did not remove a package. When you add -v/verbose.
It shows you the deps, or some. But it does not tell you it will not
remove because those packages depend on it. Seems obvious, but if you
did not use -v/verbose. You do not see those deps, and just have to
assume. Even when the deps are shown. The user must assume the package
was not removed due to deps, because its not saying explicitly.

It is not changing anything with the -c option. Other than generating
some additional generic text for the user as part of its current output
and function. With package A being the one they are trying to remove.
The rest would be boiler plate

"Package ${PN} not removed due to dependencies"

> I  think that you are actually talking about a warning upon forced
> unmerge of anything not in /var/lib/portage/world, is that correct?

That is also correct. Its two fold.

 -  If using -c, the deps are known, or at least some, and takes time.
    The output just needs to say will not remove because of deps. Not
    specifically what deps. It could in theory stop on the first
    encountered to save time, and only go further if -v is specified.
    Which it may now I have not looked at the code.

 - If using -C it should at minimum check if the package is in
   world/user installed, and say something otherwise.

That part does not require it to resolve deps. Just check world file,
assuming its correct. Though could be thrown off if say gcc, or another
was in the world file. I think the profile or set would catch that as
it does now and generate a warning, regardless.

Now in the case of no world file, or something, they maybe revert back
to some of the behavior of -c. with -C. But I would think if no world
file, or packages in world. Then the user did not emerge anything or
nuked that file.

The -C option already seems to check say a profile and set file.
Otherwise how would it know that package was in either. Seems the same
could be done for a package not in either of those files, or world. To
warn, your removing a package you did not install.

I will file 2 bugs, that should be straight forward and clear.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 19:22:47 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
>
> That part does not require it to resolve deps. Just check world file,
> assuming its correct. Though could be thrown off if say gcc, or
> another was in the world file. I think the profile or set would catch
> that as it does now and generate a warning, regardless.

Speaking of gcc in the world file. I think portage should STOP adding
packages that are in the profile or a dep to world. If you merge a
package as part of a set, I am pretty sure it does not get recorded to
world, need to confirm, could be wrong.

A rule for portage could be;

 - If the package is not in world and already installed. Do not add the
   package to world. If you are re-emerging a package already
   installed. You do not have to use the -1 option. 

I have polluted so many world files with system packages and/or
dependencies I re-emerged directly without -1. Those IMHO should never
have been recorded to that file. They were brought in by other things.
Only things in my world should be packages merged directly, not from
profile, set, or a dep.

I will file a bug on that as well.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2773 bytes --]

On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 19:22:47 -0400
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
>>
>> That part does not require it to resolve deps. Just check world file,
>> assuming its correct. Though could be thrown off if say gcc, or
>> another was in the world file. I think the profile or set would catch
>> that as it does now and generate a warning, regardless.
> 
> Speaking of gcc in the world file. I think portage should STOP adding
> packages that are in the profile or a dep to world. If you merge a
> package as part of a set, I am pretty sure it does not get recorded to
> world, need to confirm, could be wrong.
> 
> A rule for portage could be;
> 
>  - If the package is not in world and already installed. Do not add the
>    package to world. If you are re-emerging a package already
>    installed. You do not have to use the -1 option. 
> 
> I have polluted so many world files with system packages and/or
> dependencies I re-emerged directly without -1. Those IMHO should never
> have been recorded to that file. They were brought in by other things.
> Only things in my world should be packages merged directly, not from
> profile, set, or a dep.
> 
> I will file a bug on that as well.
> 
Whether Portage adds a package to a set or world file is dependent on
how you invoke emerge. Some people (like me) include sets as part of
their world, via /var/lib/portage/world_sets . At that point, sets added
to that file are basically treated as the world package list.

If gcc or other @system packages end up in your world, it's not
Portage's fault. If you don't want a package added to a set or world,
you'll need to use the -1 (--oneshot) option. I added it to my default
emerge options in make.conf for exactly that reason (clean world);
though, I have to be careful and make sure packages I care about are in
a set somewhere or --depclean will wipe'em out. In short, Portage won't
stop you from shooting yourself in the foot.

If you decide you want to add a package to world without re-merging it,
-n (--noreplace) will do the job.

I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will
catch a @system atom inside a set/world file, but that's where I'd
expect such a notification to come from. The tool can help clean up
unneeded entries in /etc/portage files, and would be a good fit for this
particular issue.

That said, having helpful messages is a good addition, but needs to be
done in a way that is unambiguous and gives the user a clear solution.

Hope this helps,

zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2959 bytes --]

On 07/11/2017 01:27 PM, Daniel Campbell wrote:
> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
>> On Mon, 10 Jul 2017 19:22:47 -0400
>> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
>>>
>>> That part does not require it to resolve deps. Just check world file,
>>> assuming its correct. Though could be thrown off if say gcc, or
>>> another was in the world file. I think the profile or set would catch
>>> that as it does now and generate a warning, regardless.
>>
>> Speaking of gcc in the world file. I think portage should STOP adding
>> packages that are in the profile or a dep to world. If you merge a
>> package as part of a set, I am pretty sure it does not get recorded to
>> world, need to confirm, could be wrong.
>>
>> A rule for portage could be;
>>
>>  - If the package is not in world and already installed. Do not add the
>>    package to world. If you are re-emerging a package already
>>    installed. You do not have to use the -1 option. 
>>
>> I have polluted so many world files with system packages and/or
>> dependencies I re-emerged directly without -1. Those IMHO should never
>> have been recorded to that file. They were brought in by other things.
>> Only things in my world should be packages merged directly, not from
>> profile, set, or a dep.
>>
>> I will file a bug on that as well.
>>
> Whether Portage adds a package to a set or world file is dependent on
> how you invoke emerge. Some people (like me) include sets as part of
> their world, via /var/lib/portage/world_sets . At that point, sets added
> to that file are basically treated as the world package list.
> 
> If gcc or other @system packages end up in your world, it's not
> Portage's fault. If you don't want a package added to a set or world,
> you'll need to use the -1 (--oneshot) option. I added it to my default
> emerge options in make.conf for exactly that reason (clean world);
> though, I have to be careful and make sure packages I care about are in
> a set somewhere or --depclean will wipe'em out. In short, Portage won't
> stop you from shooting yourself in the foot.
> 
> If you decide you want to add a package to world without re-merging it,
> -n (--noreplace) will do the job.
> 
> I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will
> catch a @system atom inside a set/world file, but that's where I'd
> expect such a notification to come from. The tool can help clean up
> unneeded entries in /etc/portage files, and would be a good fit for this
> particular issue.
> 
> That said, having helpful messages is a good addition, but needs to be
> done in a way that is unambiguous and gives the user a clear solution.
> 
> Hope this helps,
> 
> zlg
> 
Whoops.

s/gentoolkit/eix/

Sorry for the spam.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Tue, 11 Jul 2017 13:27:57 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 19:22:47 -0400
>
> > A rule for portage could be;
> > 
> >  - If the package is not in world and already installed. Do not add
> > the package to world. If you are re-emerging a package already
> >    installed. You do not have to use the -1 option. 
> > 
> > I have polluted so many world files with system packages and/or
> > dependencies I re-emerged directly without -1. Those IMHO should
> > never have been recorded to that file. They were brought in by
> > other things. Only things in my world should be packages merged
> > directly, not from profile, set, or a dep.

> Portage's fault. If you don't want a package added to a set or world,
> you'll need to use the -1 (--oneshot) option.

Did you even read above? I clearly state WITHOUT -1 option....

> I added it to my default
> emerge options in make.conf for exactly that reason (clean world);

The point is people should not have to do such. Or remember to always
use -1 when re-emerging a dep, system, world, or set package.

> though, I have to be careful and make sure packages I care about are
> in a set somewhere or --depclean will wipe'em out. In short, Portage
> won't stop you from shooting yourself in the foot.

If those package are in your world file portage will not remove on
depclean.

> If you decide you want to add a package to world without re-merging
> it, -n (--noreplace) will do the job.

Or you can add it to the world file, or your profile/packages
in /etc/portage, etc. There are other places, one does not have to
emerge every package then want in world. Just the same it should not
add stuff just the same from system, world,  sets, or deps of any of
those 3.

> That said, having helpful messages is a good addition, but needs to be
> done in a way that is unambiguous and gives the user a clear solution.

So now it must be clear to the user? That is the entire point I am
making. The output now is not clear... But in improving such now there
is concern over something no one cares about now.... Funny stuff!!!

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 4967 bytes --]

On 07/11/2017 01:57 PM, William L. Thomson Jr. wrote:
> On Tue, 11 Jul 2017 13:27:57 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
>> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
>>> On Mon, 10 Jul 2017 19:22:47 -0400
>>
>>> A rule for portage could be;
>>>
>>>  - If the package is not in world and already installed. Do not add
>>> the package to world. If you are re-emerging a package already
>>>    installed. You do not have to use the -1 option. 
>>>
>>> I have polluted so many world files with system packages and/or
>>> dependencies I re-emerged directly without -1. Those IMHO should
>>> never have been recorded to that file. They were brought in by
>>> other things. Only things in my world should be packages merged
>>> directly, not from profile, set, or a dep.
> 
>> Portage's fault. If you don't want a package added to a set or world,
>> you'll need to use the -1 (--oneshot) option.
> 
> Did you even read above? I clearly state WITHOUT -1 option....
> 
>> I added it to my default
>> emerge options in make.conf for exactly that reason (clean world);
> 
> The point is people should not have to do such. Or remember to always
> use -1 when re-emerging a dep, system, world, or set package.
> 
>> though, I have to be careful and make sure packages I care about are
>> in a set somewhere or --depclean will wipe'em out. In short, Portage
>> won't stop you from shooting yourself in the foot.
> 
> If those package are in your world file portage will not remove on
> depclean.
> 
>> If you decide you want to add a package to world without re-merging
>> it, -n (--noreplace) will do the job.
> 
> Or you can add it to the world file, or your profile/packages
> in /etc/portage, etc. There are other places, one does not have to
> emerge every package then want in world. Just the same it should not
> add stuff just the same from system, world,  sets, or deps of any of
> those 3.
> 
>> That said, having helpful messages is a good addition, but needs to be
>> done in a way that is unambiguous and gives the user a clear solution.
> 
> So now it must be clear to the user? That is the entire point I am
> making. The output now is not clear... But in improving such now there
> is concern over something no one cares about now.... Funny stuff!!!
> 

I understand where you're coming from, I just thought to give a few tips
to make life a bit easier for you since it works out pretty well for
myself. I think your idea has merit, just unsure of where the
functionality goes, since I'm not a Portage developer.

I think the hard part of implementing this will be detecting whether a
command-line-given package is (a) in a set/profile/world and (b) part of
a dependency tree (i.e. shouldn't be removed).

-c already traverses the dependency tree. This one message may mean
iterating through the list of candidate packages and comparing them
against a set/profile/world *per package*, unless the vdb/cache makes
this lookup cheap in terms of cycles. The message would be helpful,
though again, eix-test-obsolete might be the right tool to build that
feature into. I'd be interested in following the bug discussion, if
you've already filed it.

If you're really interested in the message from -C, it could be done by
checking the argument list for packages in sets or profiles. But it's
going to incur similar overhead that -c has because it necessarily has
to check some sort of list before producing the message.

I do not think this message belongs in -C output, however; -C is
intentionally meant for operations where you don't care what happens to
the dependency tree. Sometimes that's good (resolving a blocker the hard
way), sometimes it's bad (removing gcc on a whim). Warnings won't stop a
user doing that, because --unmerge is already documented with the
caveat. There must be a certain point where we as developers have to say
"You're on your own," or there will be so many rails and training wheels
that it loses value for the more experienced users, or a bunch of bugs
filed over failing to heed documentation, i.e. PEBKAC. I think -C is a
great place to draw that line.

The best way to get the ball rolling is file a feature request against
Portage and see what 'upstream' has to say. In the meantime, maybe try
your hand at hacking it. I've found people are a lot more receptive to
suggestions when you've already attempted to provide it. Even if the
solution is crap, people seem willing to help those who have the
gumption to help themselves.

Please don't interpret this e-mail as aggressive or dismissive. I'm
simply trying to offer explanation and guidance to help you make this
happen. It's clear that you care about it, so I'm sure there's a way for
this to go forward.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Tue, 11 Jul 2017 14:32:27 -0700
Daniel Campbell <zlg@gentoo.org> wrote:
>
> I understand where you're coming from, I just thought to give a few
> tips to make life a bit easier for you since it works out pretty well
> for myself. I think your idea has merit, just unsure of where the
> functionality goes, since I'm not a Portage developer.

I have been using the -1 option myself for some time. I have also moved
away from having anything in world file. I have my own profiles and
such. Just not committed to my public overlay yet.

This is mostly for others. I do what ever I need directly for myself if
it really becomes an issue for me. But I appreciate the thought!

> I think the hard part of implementing this will be detecting whether a
> command-line-given package is (a) in a set/profile/world and (b) part
> of a dependency tree (i.e. shouldn't be removed).

I do not think it will be that complex. It already does this now for
system, world, and set files. It must be looking at files already.
Having it look at say /var/lib/world is just another file/location.

> -c already traverses the dependency tree. This one message may mean
> iterating through the list of candidate packages and comparing them
> against a set/profile/world *per package*, unless the vdb/cache makes
> this lookup cheap in terms of cycles. The message would be helpful,
> though again, eix-test-obsolete might be the right tool to build that
> feature into. I'd be interested in following the bug discussion, if
> you've already filed it.

The looking at say world file is more an issue for -C than -c. -c knows
there are deps. Thus all it needs is an additional minimal message. It
already says to see deps use -v. It just does not say, why it took no
action. But actually now that I looked at -c, it is completely wrong.

I should have caught that sooner. -c does not remove a package, it just
removes its deps.

-c == --depclean.

It is not the same as -C, which is remove a package directly.

 --unmerge (-C)

Not even sure why anyone suggested -c. That explains why I use -C and
not -c, but I do use --depclean. This whole thread and topic really got
sidetracked big time with -c vs -C.

-c should never be mentioned. I was about to file a bug when I noticed
such.

emerge -c gcc, would never remove gcc, only run depclean
emerge -C will remove gcc

> If you're really interested in the message from -C, it could be done
> by checking the argument list for packages in sets or profiles. But
> it's going to incur similar overhead that -c has because it
> necessarily has to check some sort of list before producing the
> message.

Yes this is just about -C, and as stated previously. Other stuff
already hits files, this is not different really.

> I do not think this message belongs in -C output, however; -C is
> intentionally meant for operations where you don't care what happens
> to the dependency tree

Not true, as I have shown, -C will warn on removing system, world, and
set packages.

-C will NOT worn on dependencies, which it should. Using the world file
and others to know if a package is a dep or in one of those files.

> Please don't interpret this e-mail as aggressive or dismissive. I'm
> simply trying to offer explanation and guidance to help you make this
> happen. It's clear that you care about it, so I'm sure there's a way
> for this to go forward.

I do not, long as it is not insulting which it does not contain
anything of the sort. Though the discussion or mention of -c/--depclean
is really off topic. That confused and side tracked things.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

[-- Attachment #1.1: Type: text/plain, Size: 1478 bytes --]

On 12/07/17 10:05, William L. Thomson Jr. wrote:
> I should have caught that sooner. -c does not remove a package, it just
> removes its deps.
> 
> -c == --depclean.

--depclean is doing exactly what it is supposed to. If called with no
arguments, it searches for any unneeded dependencies and removes them,
however if called with a package as an argument, it will remove that
package *if it is not a dependency of another package*. Reporting
"nothing to remove" is precisely what it's supposed to do, and using
--verbose will tell you what is depending on the package.

To be clear, running '--depclean foo' does not remove dependencies of
foo, it removes foo provided it is not a dependency. It can be seen as a
dependency-aware (and thus, generally safe) --unmerge.

Making --depclean _always_ give you more information should just be a
case of adding --verbose to EMERGE_DEFAULT_OPTS.

> It is not the same as -C, which is remove a package directly.
> 
>  --unmerge (-C)

Correct, --unmerge will remove a package without considering
dependencies (give or take a few special cases). It is usually (or, at
least, should generally be) reserved for those taking a hammer to a
problem or with a particular desire to recover a broken system.

Again, it's doing exactly what it's supposed to - removing a package
you've told it to remove (unless it's one of the few
almost-always-critical packages).

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 14:17:30 +1000
"Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
>
> --depclean is doing exactly what it is supposed to. If called with no

Problem is I was talking about removing packages directly. It served no
purpose in this discussion.

Since I use --depclean, not -c. I was assuming -c was unmerge like -C,
but it is not. Others brought that up and sidetracked things. I just
did not catch and mistakenly went down that wormhole.

> 
> > It is not the same as -C, which is remove a package directly.
> > 
> >  --unmerge (-C)  
> 
> Correct, --unmerge will remove a package without considering
> dependencies (give or take a few special cases). It is usually (or, at
> least, should generally be) reserved for those taking a hammer to a
> problem or with a particular desire to recover a broken system.
> 
> Again, it's doing exactly what it's supposed to - removing a package
> you've told it to remove (unless it's one of the few
> almost-always-critical packages).

Yes and if you see bug. All I am saying is adding warnings when someone
goes to remove a dependency. Since a dependency IS a critical package :)

Add warning message when -C/--unmerge a dependency like system,
profile, and set files.
https://bugs.gentoo.org/show_bug.cgi?id=624630


-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

[-- Attachment #1.1: Type: text/plain, Size: 1167 bytes --]

On 12/07/17 14:43, William L. Thomson Jr. wrote:
>>> It is not the same as -C, which is remove a package directly.
>>>
>>>  --unmerge (-C)  
>> Correct, --unmerge will remove a package without considering
>> dependencies (give or take a few special cases). It is usually (or, at
>> least, should generally be) reserved for those taking a hammer to a
>> problem or with a particular desire to recover a broken system.
>>
>> Again, it's doing exactly what it's supposed to - removing a package
>> you've told it to remove (unless it's one of the few
>> almost-always-critical packages).
> Yes and if you see bug. All I am saying is adding warnings when someone
> goes to remove a dependency. Since a dependency IS a critical package :)
> 
> Add warning message when -C/--unmerge a dependency like system,
> profile, and set files.
> https://bugs.gentoo.org/show_bug.cgi?id=624630

My point was that --unmerge is not intended to be dependency-aware.
--depclean is. As far as I can tell, that is the point others have been
trying to make as well, when pointing out the differences between -c and -C.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 15:00:30 +1000
"Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
> 
> My point was that --unmerge is not intended to be dependency-aware.
> --depclean is. As far as I can tell, that is the point others have
> been trying to make as well, when pointing out the differences
> between -c and -C.

Sure but that is easily addressed.

How does emerge know a package is in system profile or a set?
Similar methods or others can be used to determine if a user installed
a package.

In a clean scenario, with a world file that ONLY contains stuff the
user merged directly. Then emerge could simply check that file, against
the stuff it already checks now.

Is it in system?
Is it in a set?
Is it in world?
If no to all, its a dep, warn!

It is really NOT complex, nor does it require complex depgraph or any
of the function of --depclean/-c.

Thus I say once again, mentioning anything to do with depclean is not
relevant and side tracks the discussion. There is no need. If you did
want to actually see if any deps existed. All you need is to see if
there is 1 installed package that needs the one a user is trying to
install. No need for a complete depgrah etc.

There are several ways to go about this that are not complex.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]

On 12/07/17 15:14, William L. Thomson Jr. wrote:
> Is it in system?
> Is it in a set?
> Is it in world?
> If no to all, its a dep, warn!

All this says is whether the package was explicitly installed and
recorded in world, or is a member of @system. The target package may or
may not be a dependency, may or may not have been --oneshot'd.

It may have been installed as a dependency but the requiring package was
removed, or may have been installed as an orphan but is now a
dependency. Assuming that if it's not in a set it must be a dependency
is incorrect and misleading.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 15:19:32 +1000
"Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:

> On 12/07/17 15:14, William L. Thomson Jr. wrote:
> > Is it in system?
> > Is it in a set?
> > Is it in world?
> > If no to all, its a dep, warn!  
> 
> All this says is whether the package was explicitly installed and
> recorded in world, or is a member of @system. The target package may
> or may not be a dependency, may or may not have been --oneshot'd.

Then when the user sees the warning they can discard knowing they
merged the package with --oneshot.

What harm does a warning do?

> It may have been installed as a dependency but the requiring package
> was removed,

Then the person failed to run --depclean and maintain their system.
Either way, did the person install the package directly?

If the package was not installed by the user. Should they not be warned
about removing something they did not install?

> or may have been installed as an orphan but is now a
> dependency. 

Now being a dependency the warning would be valid.

>Assuming that if it's not in a set it must be a dependency  is
>incorrect and misleading.

Again there are various ways. There cannot be that much overhead to
check if a single package depends on one being removed. If you cannot
use simpler methods as mentioned.

Clearly people have objections to warnings about packages users did not
install themselves....

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

[-- Attachment #1.1: Type: text/plain, Size: 2509 bytes --]

On 12/07/17 15:36, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:19:32 +1000
> "Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
> 
>> On 12/07/17 15:14, William L. Thomson Jr. wrote:
>>> Is it in system?
>>> Is it in a set?
>>> Is it in world?
>>> If no to all, its a dep, warn!  
>>
>> All this says is whether the package was explicitly installed and
>> recorded in world, or is a member of @system. The target package may
>> or may not be a dependency, may or may not have been --oneshot'd.
> 
> Then when the user sees the warning they can discard knowing they
> merged the package with --oneshot.

I have trouble remembering what I ate for dinner last night, let alone
what I may or may not have merged a week, month or year ago, or what
options I used when merging it.

> What harm does a warning do?

Depends on the user, which can't really be avoided, but means that
warnings should be clear and meaningful, otherwise they become
background noise.

>> It may have been installed as a dependency but the requiring package
>> was removed,
> 
> Then the person failed to run --depclean and maintain their system.
> Either way, did the person install the package directly?
> 
> If the package was not installed by the user. Should they not be warned
> about removing something they did not install?

Such as:

emerge --unmerge dev-python/keyring
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies before
 * removing packages.

>> or may have been installed as an orphan but is now a
>> dependency. 
> 
> Now being a dependency the warning would be valid.

"Sometimes being accurate" is not the most noble of goals.

>> Assuming that if it's not in a set it must be a dependency  is
>> incorrect and misleading.
> 
> Again there are various ways. There cannot be that much overhead to
> check if a single package depends on one being removed. If you cannot
> use simpler methods as mentioned.
> 
> Clearly people have objections to warnings about packages users did not
> install themselves....
> 

So the idea is to duplicate the functionality of '--depclean <package>'
without actually checking to see if the package is a dependency, only
whether it is listed in a set; or to check if it's a dependency of
/something/ and, if so, redirect the user to the command they should be
using anyway?

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 15:49:14 +1000
"Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
>
> I have trouble remembering what I ate for dinner last night, let alone
> what I may or may not have merged a week, month or year ago, or what
> options I used when merging it.

And if you used --oneshot, it is also saying you are not maintaining
your system or ever running --depclean. Since anything you installed
via --oneshot would be removed with --depclean.

> > What harm does a warning do?  
> 
> Depends on the user, which can't really be avoided, but means that
> warnings should be clear and meaningful, otherwise they become
> background noise.

The example in the bug is as clear is it can get.

!!! 'sys-devel/gcc' is a dependency of another package on your system
or
!!! 'sys-devel/gcc' is a package not found in system profile or world
or
!!! 'sys-devel/gcc' may not have been installed by you
or
some other message....

> Such as:
> 
> emerge --unmerge dev-python/keyring
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean <atom>` to check for reverse dependencies
> before
>  * removing packages.

Didn't you just say something about meaningful output vs noise? That is
always outputted and ends up becoming what you are saying. Funny!
 
> >> or may have been installed as an orphan but is now a
> >> dependency.   
> > 
> > Now being a dependency the warning would be valid.  
> 
> "Sometimes being accurate" is not the most noble of goals.

What?

> So the idea is to duplicate the functionality of '--depclean
> <package>

NO!!!

emerge --depclean gcc 

is not the same as 

emerge --umerge gcc

Depclean the user is cleaning things they are not aware of. Unmerge the
user is removing something directly. They may think they do not need it.

>' without actually checking to see if the package is a
> dependency,

Word it how ever. If the user did not install, they should be warned on
removal of a package they did not install.

> only whether it is listed in a set; or to check if it's a
> dependency of /something/ and, if so, redirect the user to the
> command they should be using anyway?

You mean like emerge --unmerge does already that you pointed out
above. After mentioning useful messages vs noise.  Again funny!

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

[-- Attachment #1.1: Type: text/plain, Size: 3646 bytes --]

On 12/07/17 16:06, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:49:14 +1000
> "Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:
>>
>> I have trouble remembering what I ate for dinner last night, let alone
>> what I may or may not have merged a week, month or year ago, or what
>> options I used when merging it.
> 
> And if you used --oneshot, it is also saying you are not maintaining
> your system or ever running --depclean. Since anything you installed
> via --oneshot would be removed with --depclean.

If my concern in removing a package was whether it was a dependency, it
would make more sense to use --depclean in the first place. If I'm using
--unmerge, it's because I want the package unmerged regardless.

>>> What harm does a warning do?  
>>
>> Depends on the user, which can't really be avoided, but means that
>> warnings should be clear and meaningful, otherwise they become
>> background noise.
> 
> The example in the bug is as clear is it can get.
> 
> !!! 'sys-devel/gcc' is a dependency of another package on your system
> or
> !!! 'sys-devel/gcc' is a package not found in system profile or world
> or
> !!! 'sys-devel/gcc' may not have been installed by you
> or
> some other message....
> 
>> Such as:
>>
>> emerge --unmerge dev-python/keyring
>>  * This action can remove important packages! In order to be safer,
>> use
>>  * `emerge -pv --depclean <atom>` to check for reverse dependencies
>> before
>>  * removing packages.
> 
> Didn't you just say something about meaningful output vs noise? That is
> always outputted and ends up becoming what you are saying. Funny!

And your suggesting adding more noise to it... Funny, I know.

>>>> or may have been installed as an orphan but is now a
>>>> dependency.   
>>>
>>> Now being a dependency the warning would be valid.  
>>
>> "Sometimes being accurate" is not the most noble of goals.
> 
> What?
> 
>> So the idea is to duplicate the functionality of '--depclean
>> <package>
> 
> NO!!!
> 
> emerge --depclean gcc 
> 
> is not the same as 
> 
> emerge --umerge gcc
> 
> Depclean the user is cleaning things they are not aware of. Unmerge the
> user is removing something directly. They may think they do not need it.

No.

'--depclean' is the user removing things they are not aware of.

'--depclean foo' is the user removing something they /are/ aware of *if
it's not a dependency*.

'--unmerge foo' is the user explicitly removing something regardless of
whether it's a dependency.

Therefore, '--depclean foo' can be seen as a safe '--unmerge foo' which,
from what I understand, is what you're aiming for.

>> ' without actually checking to see if the package is a
>> dependency,
> 
> Word it how ever. If the user did not install, they should be warned on
> removal of a package they did not install.

That's what the current warning to --unmerge says - removing packages
can break things, so please make sure this isn't a dependency and you
really want to remove this.

>> only whether it is listed in a set; or to check if it's a
>> dependency of /something/ and, if so, redirect the user to the
>> command they should be using anyway?
> 
> You mean like emerge --unmerge does already that you pointed out
> above. After mentioning useful messages vs noise.  Again funny!

How does replacing one warning with another warning that may or may not
be meaningful ("maybe it's a dep, maybe it isn't" as opposed to "this
can be dangerous, please make sure you know what you're doing") make it
any better?

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 16:40:11 +1000
"Sam Jorna (wraeth)" <wraeth@gentoo.org> wrote:

> If my concern in removing a package was whether it was a dependency,
> it would make more sense to use --depclean in the first place. If I'm
> using --unmerge, it's because I want the package unmerged regardless.

But you can't remember what you installed or ate for dinner. What if you
are removing something you need?

> > Didn't you just say something about meaningful output vs noise?
> > That is always outputted and ends up becoming what you are saying.
> > Funny!  
> >
> And your suggesting adding more noise to it... Funny, I know.

No a warning that mentions the package not being removed is not noise.
It is useful output, like the warnings that exist for other things now.

I guess in your opinion this warning is noise to you.

!!! 'sys-devel/gcc' is part of your system profile.
!!! Unmerging it may be damaging to your system.

It is YOUR comments that are funny, and going in a circular argument
just to be argumentative and bringing nothing useful to the discussion.
Which should be over now that bugs are filed....

> > Depclean the user is cleaning things they are not aware of. Unmerge
> > the user is removing something directly. They may think they do not
> > need it.  
> 
> No.
> 
> '--depclean' is the user removing things they are not aware of.

You literally just re-typed what I did above replacing cleaning with
removing. Are you paying any attention?

> '--depclean foo' is the user removing something they /are/ aware of
> *if it's not a dependency*.

That does not work the same. It will not remove a package from world.

> '--unmerge foo' is the user explicitly removing something regardless
> of whether it's a dependency.

BUT they are warned now for things that are in a profile or set. Thus
they should be warned if a dependency. Its simply, but clearly your
having a hard time grasping.

> Therefore, '--depclean foo' can be seen as a safe '--unmerge foo'
> which, from what I understand, is what you're aiming for.

No, as they are not the same. You cannot remember what you ate. Please
stop trying to assume what I am after. Clearly we are very different. I
know what I ate last night...

> That's what the current warning to --unmerge says - removing packages
> can break things, so please make sure this isn't a dependency and you
> really want to remove this.

They do not say anything about dependencies. It says the same message
for everything. In some cases for system and set packages you get a
warning.

> How does replacing one warning with another warning that may or may
> not be meaningful ("maybe it's a dep, maybe it isn't" as opposed to
> "this can be dangerous, please make sure you know what you're doing")
> make it any better?

It is not replacing a warning. It is adding the same warning that exist
in other situations in one it does not exists now, removing
dependencies.

Clearly you are having a hard time grasping this very simple concept.
I am done, reply if you like, but this thread is serious noise now...

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna]

[-- Attachment #1.1: Type: text/plain, Size: 1560 bytes --]

On 13/07/17 00:19, William L. Thomson Jr. wrote:
> It is YOUR comments that are funny, and going in a circular argument
> just to be argumentative and bringing nothing useful to the discussion.
> Which should be over now that bugs are filed....

I'm not trying to be argumentative or antagonistic, I'm trying to
understand how your replacement warning differs from what's already
available and adds value.

>> '--depclean foo' is the user removing something they /are/ aware of
>> *if it's not a dependency*.
> 
> That does not work the same. It will not remove a package from world.

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -C apg
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies before
 * removing packages.
<snip>
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

...

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -c apg

Calculating dependencies... done!
>>> Calculating removal order...
<snip>
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

> Clearly you are having a hard time grasping this very simple concept.
> I am done, reply if you like, but this thread is serious noise now...

Clearly, hence why I was trying to understand what difference your
proposal offered. But since we're moving on to serious things now, I
guess I /am/ done with this thread.

-- 
Sam Jorna (wraeth) <wraeth@gentoo.org>
GnuPG Key: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Thu, 13 Jul 2017 01:03:00 +1000
Sam Jorna <wraeth@gentoo.org> wrote:

> On 13/07/17 00:19, William L. Thomson Jr. wrote:
> > It is YOUR comments that are funny, and going in a circular argument
> > just to be argumentative and bringing nothing useful to the
> > discussion. Which should be over now that bugs are filed....  
> 
> I'm not trying to be argumentative or antagonistic, I'm trying to
> understand how your replacement warning differs from what's already
> available and adds value.

It is similar to the warnings that exist now. To my knowledge, other
than generic messages that are always there, and a user is likely to
ignore as noise.

Nothing to my knowledge will tell you that someone was not removed
because it a was a dependency. Neither -c, nor -C does this. I get -C
maybe unware, but -c is not. Even when adding -v to -c, it does not
explicitly say the package was not removed because another needs it.
That is assumed, and IMHO the user is left wanting as previously stated.

> $ emerge -C apg
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean <atom>` to check for reverse dependencies
> before
>  * removing packages.

That is my point. That message is always there. The chance that it is
ignored is very high.

> Clearly, hence why I was trying to understand what difference your
> proposal offered. But since we're moving on to serious things now, I
> guess I /am/ done with this thread.
 
I was proposing to provided further information to the user unique to
that situation. Not removing because it is a dependency.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Gordon Pettey]

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

On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna <wraeth@gentoo.org> wrote:
>
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean <atom>` to check for reverse dependencies
> > before
> >  * removing packages.
>
> That is my point. That message is always there. The chance that it is
> ignored is very high.
>
>
Stop signs on the road are also always there. If you get arrested for
ignoring it, it is not because the stop signs are always there, it is
because you ignored it. Don't ignore the warning.

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

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[M. J. Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 906 bytes --]

On 12/07/17 17:07, Gordon Pettey wrote:
> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com <mailto:wlt-ml@o-sinc.com>> wrote:
>
>     On Thu, 13 Jul 2017 01:03:00 +1000
>     Sam Jorna <wraeth@gentoo.org <mailto:wraeth@gentoo.org>> wrote:
>
>     > $ emerge -C apg
>     >  * This action can remove important packages! In order to be safer,
>     > use
>     >  * `emerge -pv --depclean <atom>` to check for reverse dependencies
>     > before
>     >  * removing packages.
>
>     That is my point. That message is always there. The chance that it is
>     ignored is very high.
>
>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
Can't help but think of "special snowflake" here ....

*cue flamewar...*

[-- Attachment #1.1.2: Type: text/html, Size: 2197 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 17:23:43 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> On 12/07/17 17:07, Gordon Pettey wrote:
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > <wlt-ml@o-sinc.com <mailto:wlt-ml@o-sinc.com>> wrote:

> >     That is my point. That message is always there. The chance that
> > it is ignored is very high.
> >
> >
> > Stop signs on the road are also always there. If you get arrested
> > for ignoring it, it is not because the stop signs are always there,
> > it is because you ignored it. Don't ignore the warning.  
> Can't help but think of "special snowflake" here ....

More like saying something to me because it is me, despite that I
literally pointed that out to others. In a situation that actually
matters. This should be said to others not me. But everyone feels ilke
they need to comment something to me, that applies to another, but not
said to that other.

Again
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Really funny stuff!!!!

--
-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Pacho Ramos]

El mié, 12-07-2017 a las 12:38 -0400, William L. Thomson Jr. escribió:
> On Wed, 12 Jul 2017 17:23:43 +0100
> "M. J. Everitt" <m.j.everitt@iee.org> wrote:
> 
> > On 12/07/17 17:07, Gordon Pettey wrote:
> > > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > > <wlt-ml@o-sinc.com <mailto:wlt-ml@o-sinc.com>> wrote:
> > >     That is my point. That message is always there. The chance that
> > > it is ignored is very high.
> > > 
> > > 
> > > Stop signs on the road are also always there. If you get arrested
> > > for ignoring it, it is not because the stop signs are always there,
> > > it is because you ignored it. Don't ignore the warning.  
> > 
> > Can't help but think of "special snowflake" here ....
> 
> More like saying something to me because it is me, despite that I
> literally pointed that out to others. In a situation that actually
> matters. This should be said to others not me. But everyone feels ilke
> they need to comment something to me, that applies to another, but not
> said to that other.
> 
> Again
> https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b2
> 4
> 
> Really funny stuff!!!!
> 
> --

After re-reading all the thread again:
https://lists.gt.net/gentoo/dev/327773/?page=1;mh=-1;

I think there is no point in continuing replying forever to this thread as I
think all the technical issues has now being, at least, clarified and forwarded
to the right people. As I have understood most of them belong to Portage team
and now that the bug reports with the concrete suggestions were filled, they
will be able to deal with them (either working on implementing the desired
changes or either declining to do that if they have other opinions based on the
way portage is supposed to be used by us). 

Then, can we please switch to different and more productive things to do? :)

Thanks a lot!

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 11:07:00 -0500
Gordon Pettey <petteyg359@gmail.com> wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
>
> > That is my point. That message is always there. The chance that it
> > is ignored is very high.
> >
> >
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.

And again another commenting who did not follow the thread. Talking to
the wrong person, replying at the wrong point.

Who is ignoring warnings? Me or others?
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Guess you missed where I was pointing out important warnings others
were ignoring. Much more so than the generic output that is always
present with emerge -C/--unmerge.

Also in what country do you get arrested for running a stop sign?

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Raymond Jennings]

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

On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey <petteyg359@gmail.com> wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> wlt-ml@o-sinc.com> wrote:
>
>> On Thu, 13 Jul 2017 01:03:00 +1000
>> Sam Jorna <wraeth@gentoo.org> wrote:
>>
>> > $ emerge -C apg
>> >  * This action can remove important packages! In order to be safer,
>> > use
>> >  * `emerge -pv --depclean <atom>` to check for reverse dependencies
>> > before
>> >  * removing packages.
>>
>> That is my point. That message is always there. The chance that it is
>> ignored is very high.
>>
>>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
>

Just to be pedantic:

You can usually only be arrested for felonies and misdemeanors.

Ignoring a stop sign and most traffic related offenses in general are
infractions or violations.  For those, you just get cited with a nasty
ticket and an annoying fine.

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

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Aaron W. Swenson]

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

On 2017-07-15 01:34, Raymond Jennings wrote:
> On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey <petteyg359@gmail.com> wrote:
> 
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> > wlt-ml@o-sinc.com> wrote:
> >
> >> On Thu, 13 Jul 2017 01:03:00 +1000
> >> Sam Jorna <wraeth@gentoo.org> wrote:
> >>
> >> > $ emerge -C apg
> >> >  * This action can remove important packages! In order to be safer,
> >> > use
> >> >  * `emerge -pv --depclean <atom>` to check for reverse dependencies
> >> > before
> >> >  * removing packages.
> >>
> >> That is my point. That message is always there. The chance that it is
> >> ignored is very high.
> >>
> >>
> > Stop signs on the road are also always there. If you get arrested for
> > ignoring it, it is not because the stop signs are always there, it is
> > because you ignored it. Don't ignore the warning.
> >
> 
> Just to be pedantic:
> 
> You can usually only be arrested for felonies and misdemeanors.
> 
> Ignoring a stop sign and most traffic related offenses in general are
> infractions or violations.  For those, you just get cited with a nasty
> ticket and an annoying fine.

Well, that depends. One stop sign and no other vehicles involved? Just a
ticket.

Run a stop sign and while swerving around the road risking the lives of
others because you can’t be bother to pay attention to the signs? That’s
an arrest.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 376 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Walter Dnes]

On Tue, Jul 11, 2017 at 04:57:21PM -0400, William L. Thomson Jr. wrote
> On Tue, 11 Jul 2017 13:27:57 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
> > Portage's fault. If you don't want a package added to a set or world,
> > you'll need to use the -1 (--oneshot) option.
> 
> Did you even read above? I clearly state WITHOUT -1 option....
> 
> > I added it to my default
> > emerge options in make.conf for exactly that reason (clean world);
> 
> The point is people should not have to do such. Or remember to always
> use -1 when re-emerging a dep, system, world, or set package.

  Step back for a minute, and relax.  There is a reason you're getting
blowback.  You're asking for changes that would affect everybody else.
This is similar in principle to what Lennart Poettering did, and you're
getting the same reaction he got.  I understand that *YOU* want changes
to how Portage works on *YOUR* machine.  No problem.  Set
EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
--depclean then check the small script I posted elsewhere in this
thread.  Portage has many customization options; use them.

  If you can't be bothered to use available customization options to set
up your machine to your liking, but ask for a change of defaults that
also affects everybody else, don't be surprised at the negative reaction.
You would've gotten a much better reception, if you had gone to the
gentoo-user list and asked "How do I tweak Portage to do this, that, and
the other".

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1234 bytes --]

On 12/07/17 04:22, Walter Dnes wrote:
>
>   Step back for a minute, and relax.  There is a reason you're getting
> blowback.  You're asking for changes that would affect everybody else.
> This is similar in principle to what Lennart Poettering did, and you're
> getting the same reaction he got.  I understand that *YOU* want changes
> to how Portage works on *YOUR* machine.  No problem.  Set
> EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
> --depclean then check the small script I posted elsewhere in this
> thread.  Portage has many customization options; use them.
>
>   If you can't be bothered to use available customization options to set
> up your machine to your liking, but ask for a change of defaults that
> also affects everybody else, don't be surprised at the negative reaction.
> You would've gotten a much better reception, if you had gone to the
> gentoo-user list and asked "How do I tweak Portage to do this, that, and
> the other".
>
+1

Of course, you can do what Poettering did, and write your own solution
.. or fork portage to do things the way -you- want .. but don't reinvent
the wheel for the rest of us .. that's what Choice and Gentoo is all
about ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 04:43:41 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:
> 
> Of course, you can do what Poettering did, and write your own solution
> .. or fork portage to do things the way -you- want .. but don't
> reinvent the wheel for the rest of us .. that's what Choice and
> Gentoo is all about ...


Its not for me. It is not re-inventing the wheel. It is safe guard
stuff that benefits all. See bugs.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Tue, 11 Jul 2017 23:22:12 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
>   Step back for a minute, and relax.  There is a reason you're getting
> blowback.  You're asking for changes that would affect everybody else.
> This is similar in principle to what Lennart Poettering did, and
> you're getting the same reaction he got.  I understand that *YOU*
> want changes to how Portage works on *YOUR* machine.  No problem.  Set
> EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
> --depclean then check the small script I posted elsewhere in this
> thread.  Portage has many customization options; use them.

I am relaxed, and if you understand what I am proposing. It will only
help everyone. There is no harm in adding warmings that provide
additional information.

Preventing stuff from being added to world is moot, as that stuff comes
from something else, profile, set, etc. It being added to world serves
no purpose, Just can cause issues down the road. Stuff remaining that
may have not been wanted, but ended up in world so persists and gets
updated, etc.

What purpose does system profile packages saved in world serve?

These changes are NOT for me... I can edit and code myself. This is for
others per this discussion. Others brought up sets accidentally
removing system stuff, etc. Thus these ideas came up as ways to prevent
others from shooting themselves in the foot.

The blowback is mostly because its me, and people are misunderstanding
things. Like the mention of -c/--depclean. Which does not have the same
function as -C/--unmerge. That sidetracked things and added nothing.

>   If you can't be bothered to use available customization options to
> set up your machine to your liking, but ask for a change of defaults
> that also affects everybody else, don't be surprised at the negative
> reaction. You would've gotten a much better reception, if you had
> gone to the gentoo-user list and asked "How do I tweak Portage to do
> this, that, and the other".

How many times do I have to say I use -1, and others like -O.  People
do not pay attention...

Again I do much of this via ansible and profiles. I am not even using a
world file, or sets even. I did use sets before my custom profiles. Did
I always use -1 for the past over a decade no? Should all users have to
in order to prevent needless stuff from being recorded in world.

Please do not assume what I am or am not doing and problems I am not
having. This is stuff for others. I am seeing problems that OTHERS can
run into per the discussion on sets. From things OTHERS mentioned as
issues with using sets.

Bugs are filed.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Wed, 12 Jul 2017 00:00:24 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> Again I do much of this via ansible and profiles. I am not even using
> a world file, or sets even. I did use sets before my custom profiles.
> Did I always use -1 for the past over a decade no? Should all users
> have to in order to prevent needless stuff from being recorded in
> world.

The whole purpose of this topic. I wanted to use sets in my custom
profiles and I could not.... I did not want to mess with meta ebuilds.
I make enough ebulids as it is. Maybe more than any other single.[1]

Think about that? Why would I be messing with profiles, if I am dealing
with things one off? I only am invoking emerge on things I am actively
developing or packaging. The rest is handled via other means.

I do appreciate all the lessons and instructions. Not sure when people
will learn to stop assuming things about others. Many married couples
barely know their spouse. You have no chance online....

1. https://github.com/Obsidian-StudiosInc/os-xtoo/

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

  I have a script I've written for my own use.  It's not 100% polished,
but it does the job for me.  My "autodepclean" script runs
"emerge --pretend --depclean", and reformats the output into another
script, named "cleanscript", which contains a bunch of lines like...

emerge --depclean --verbose =fu-bar/xyz-1.2.3

  Before running "./cleanscript", I check it for problems.  Here's the
autodepclean script...

#!/bin/bash
# autodepclean script v 0.04 released under GPL v3 by Walter Dnes 2012/07/09
# Generates a file "cleanscript" to remove unused ebuilds, including
# buildtime-only dependancies.
#
# Warning; this script is still beta.  I recommend that you check the output
# in cleanscript before running it.
#
# With the arrival of "virtual/editor", the script now suggests removing
# app-editors/nano, which may not be what you want.  If you want to keep
# nano, put it into world
#
# version 0.03 disables the removal of gentoo-sources.  Your current kernel
# is not always the most recent one in /usr/src.
#
# version 0.04 adds "--verbose" to the "emerge --depclean".  This makes it
# easier to track down circular dependancies.
#
echo "#!/bin/bash" > cleanscript
echo "#" >> cleanscript
emerge --pretend --depclean |\
  grep -A1 "^ .*/" |\
  grep -v "^ \*" |\
  grep -v "^--" |\
  sed ":/: {
N
s:\n::
s/    selected: /-/
s/^ /emerge --depclean --verbose =/
}" | grep -v "gentoo-sources" >> cleanscript
echo "revdep-rebuild" >> cleanscript
chmod 744 cleanscript

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

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

On Mon, Jul 10, 2017 at 3:27 PM, William L. Thomson Jr. <wlt-ml@o-sinc.com>
wrote:

>
>
> Not sure why anyone would have objection to such a warning like exists
> for other things. Or providing more information to the user as to why a
> package was not removed, or should not be removed.
>
> --
> William L. Thomson Jr.
>
If you want dependencies checked, use the correct option which checks
them.  This takes significantly longer than -C, as it's significantly more
complex to check for.

As far as I can tell, you are literally asking for -C to behave like -c,
when you could just be using -c instead.

-Ben

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 15:36:11 -0500
Ben Kohler <bkohler@gmail.com> wrote:
>
> If you want dependencies checked, use the correct option which checks
> them.  This takes significantly longer than -C, as it's significantly
> more complex to check for.
> 
> As far as I can tell, you are literally asking for -C to behave like
> -c, when you could just be using -c instead.

No I simply want warnings like that exist for profiles and set packages.

Also more information when attempting to remove a package that is not
removed.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:47 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler <bkohler@gmail.com> wrote:
>>
>> If you want dependencies checked, use the correct option which checks
>> them.  This takes significantly longer than -C, as it's significantly
>> more complex to check for.
>>
>> As far as I can tell, you are literally asking for -C to behave like
>> -c, when you could just be using -c instead.
>
> No I simply want warnings like that exist for profiles and set packages.
>
> Also more information when attempting to remove a package that is not
> removed.

Well, as was pointed out, doing that comes at a performance cost.
Would it not make sense to have an option to skip dependency checks
for use in scripts/etc where you know it is safe to do so?

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

Stop getting lost in the weeds!!!!
You all are making this about -c vs -C. I am not talking about that!

LET ME CLARIFY....

When using -C, portage SHOULD warn for dependencies like it does for
profile and set packages, PERIOD. NOTHING to do with -c vs -C.

When using -c the output should say in layman's terms,
"Not removing package A because it is a dependency" 

Again nothing to do with -c vs -C. So PLEASE stop with that!

Two things very straightforward and simple. No clue why others keep
making this about a use -c vs -C. That does NOT change the lack of
warnings or information I am speaking about for BOTH!

Amazing how things can be off tracked and miss the entire point. I do
not care if you use -c or -C. BOTH lack the same warnings and
information. That is what I am talking about.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Michał Górny]

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

On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> Stop getting lost in the weeds!!!!
> You all are making this about -c vs -C. I am not talking about that!
> 
> LET ME CLARIFY....
> 
> When using -C, portage SHOULD warn for dependencies like it does for
> profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> 
> When using -c the output should say in layman's terms,
> "Not removing package A because it is a dependency" 
> 
> Again nothing to do with -c vs -C. So PLEASE stop with that!
> 
> Two things very straightforward and simple. No clue why others keep
> making this about a use -c vs -C. That does NOT change the lack of
> warnings or information I am speaking about for BOTH!
> 
> Amazing how things can be off tracked and miss the entire point. I do
> not care if you use -c or -C. BOTH lack the same warnings and
> information. That is what I am talking about.

William, I'm not sure if you're aware of how package managers work but
checking reverse dependencies of a package takes significant amount of
time. Changing -C to do that would be a serious performance regression.
Which would result in users requesting yet another option to disable
this.

I should also point out that these are Portage implementation specifics
that do not belong on this mailing list. The issues with Portage are
reported on bugs.gentoo.org, in the 'Portage Development' product. If
you have any problems with using Portage, please use the gentoo-user
mailing list or any other user-oriented media.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[Gordon Pettey]

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

On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgorny@gentoo.org> wrote:

> On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > Stop getting lost in the weeds!!!!
> > You all are making this about -c vs -C. I am not talking about that!
> >
> > LET ME CLARIFY....
> >
> > When using -C, portage SHOULD warn for dependencies like it does for
> > profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> >
> > When using -c the output should say in layman's terms,
> > "Not removing package A because it is a dependency"
>
> William, I'm not sure if you're aware of how package managers work but
> checking reverse dependencies of a package takes significant amount of
> time.


for x in $(eix -I --only-names); do time equery g $x > /dev/null; done

The only single package on my system that took more than 2 seconds total
time was gcc. The idea that that is too much time to add to emerge -c or
-C, which in my experience already takes multiple seconds to run anyway is
kind of silly.

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[Michał Górny]

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

On pon, 2017-07-10 at 17:47 -0500, Gordon Pettey wrote:
> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > > Stop getting lost in the weeds!!!!
> > > You all are making this about -c vs -C. I am not talking about that!
> > > 
> > > LET ME CLARIFY....
> > > 
> > > When using -C, portage SHOULD warn for dependencies like it does for
> > > profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> > > 
> > > When using -c the output should say in layman's terms,
> > > "Not removing package A because it is a dependency"
> > 
> > William, I'm not sure if you're aware of how package managers work but
> > checking reverse dependencies of a package takes significant amount of
> > time.
> 
> 
> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> 
> The only single package on my system that took more than 2 seconds total
> time was gcc. The idea that that is too much time to add to emerge -c or
> -C, which in my experience already takes multiple seconds to run anyway is
> kind of silly.

What's even more 'kind of silly' is you claiming things to be kind of
silly based on wrong understand of what needs to be done and benchmarks
that are done using completely different tooling.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 17:47:45 -0500
Gordon Pettey <petteyg359@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> 
> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > > Stop getting lost in the weeds!!!!
> > > You all are making this about -c vs -C. I am not talking about
> > > that!
> > >
> > > LET ME CLARIFY....
> > >
> > > When using -C, portage SHOULD warn for dependencies like it does
> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> > >
> > > When using -c the output should say in layman's terms,
> > > "Not removing package A because it is a dependency"
> >
> > William, I'm not sure if you're aware of how package managers work
> > but checking reverse dependencies of a package takes significant
> > amount of time.
> 
> 
> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> 
> The only single package on my system that took more than 2 seconds
> total time was gcc. The idea that that is too much time to add to
> emerge -c or -C, which in my experience already takes multiple
> seconds to run anyway is kind of silly.

IMHO anyone complaining about time taking for dependency resolution
etc. They should spend THEIR time writing stuff in a real native
language for speed.

The difference I see with jem[1] vs java-config, is ridiculous.
Sometimes I merge hundreds of java packages. All those milliseconds add
up. Not to mention resources, ram, CPU, and all drains your battery...

If aspects of portage were done in C or C++, or maybe even Go. There
would be substantial performance improvements. The existing python code
can remain. Python can load and call functions from C/C++ DSO. And vice
versa, calling Python code from C/C++. I would say C vs C++ but that is
up to others.

Put my time where my mouth is... Well I did, its called jem. What is
jem? Its java-config ported to C. I would be looking to port more of
Gentoo's tools to C for longevity and speed. Not speed of development,
but speed for everyone else. Instead I am doing C for other projects.

1. https://github.com/Obsidian-StudiosInc/jem

P.S.
jem does need a bit more work to replace java-config entirely. Its
designed to not be Gentoo specific. There is little interest from
Gentoo, much less outside. Thus its more a case study than anything
benefiting anyone including myself. I will further it as I have
interest and time permits. Still have a few more defects to address.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[R0b0t1]

On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Mon, 10 Jul 2017 17:47:45 -0500
> Gordon Pettey <petteyg359@gmail.com> wrote:
>
>> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>
>> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
>> > > Stop getting lost in the weeds!!!!
>> > > You all are making this about -c vs -C. I am not talking about
>> > > that!
>> > >
>> > > LET ME CLARIFY....
>> > >
>> > > When using -C, portage SHOULD warn for dependencies like it does
>> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
>> > >
>> > > When using -c the output should say in layman's terms,
>> > > "Not removing package A because it is a dependency"
>> >
>> > William, I'm not sure if you're aware of how package managers work
>> > but checking reverse dependencies of a package takes significant
>> > amount of time.
>>
>>
>> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
>>
>> The only single package on my system that took more than 2 seconds
>> total time was gcc. The idea that that is too much time to add to
>> emerge -c or -C, which in my experience already takes multiple
>> seconds to run anyway is kind of silly.
>
> IMHO anyone complaining about time taking for dependency resolution
> etc. They should spend THEIR time writing stuff in a real native
> language for speed.
>
> The difference I see with jem[1] vs java-config, is ridiculous.
> Sometimes I merge hundreds of java packages. All those milliseconds add
> up. Not to mention resources, ram, CPU, and all drains your battery...
>
> If aspects of portage were done in C or C++, or maybe even Go. There
> would be substantial performance improvements. The existing python code
> can remain. Python can load and call functions from C/C++ DSO. And vice
> versa, calling Python code from C/C++. I would say C vs C++ but that is
> up to others.
>

https://wiki.gentoo.org/wiki/Q_applets

What you're suggesting is actually really hard, and the root of the
problems tend to be graph traversals and path searches (for
dependencies) not so much miscellaneous milliseconds spent in
interpreter overhead.

Then again, I suppose there will be people on computers slow enough
where the latter does make a difference.

> Put my time where my mouth is... Well I did, its called jem. What is
> jem? Its java-config ported to C. I would be looking to port more of
> Gentoo's tools to C for longevity and speed. Not speed of development,
> but speed for everyone else. Instead I am doing C for other projects.
>
> 1. https://github.com/Obsidian-StudiosInc/jem
>
> P.S.
> jem does need a bit more work to replace java-config entirely. Its
> designed to not be Gentoo specific. There is little interest from
> Gentoo, much less outside. Thus its more a case study than anything
> benefiting anyone including myself. I will further it as I have
> interest and time permits. Still have a few more defects to address.
>

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Raymond Jennings]

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

If I may ask, does anyone have any profiling information one way or the
other to shed light on the situation?

On Mon, Jul 10, 2017 at 6:12 PM, R0b0t1 <r030t1@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
> > On Mon, 10 Jul 2017 17:47:45 -0500
> > Gordon Pettey <petteyg359@gmail.com> wrote:
> >
> >> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny <mgorny@gentoo.org>
> >> wrote:
> >>
> >> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> >> > > Stop getting lost in the weeds!!!!
> >> > > You all are making this about -c vs -C. I am not talking about
> >> > > that!
> >> > >
> >> > > LET ME CLARIFY....
> >> > >
> >> > > When using -C, portage SHOULD warn for dependencies like it does
> >> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> >> > >
> >> > > When using -c the output should say in layman's terms,
> >> > > "Not removing package A because it is a dependency"
> >> >
> >> > William, I'm not sure if you're aware of how package managers work
> >> > but checking reverse dependencies of a package takes significant
> >> > amount of time.
> >>
> >>
> >> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> >>
> >> The only single package on my system that took more than 2 seconds
> >> total time was gcc. The idea that that is too much time to add to
> >> emerge -c or -C, which in my experience already takes multiple
> >> seconds to run anyway is kind of silly.
> >
> > IMHO anyone complaining about time taking for dependency resolution
> > etc. They should spend THEIR time writing stuff in a real native
> > language for speed.
> >
> > The difference I see with jem[1] vs java-config, is ridiculous.
> > Sometimes I merge hundreds of java packages. All those milliseconds add
> > up. Not to mention resources, ram, CPU, and all drains your battery...
> >
> > If aspects of portage were done in C or C++, or maybe even Go. There
> > would be substantial performance improvements. The existing python code
> > can remain. Python can load and call functions from C/C++ DSO. And vice
> > versa, calling Python code from C/C++. I would say C vs C++ but that is
> > up to others.
> >
>
> https://wiki.gentoo.org/wiki/Q_applets
>
> What you're suggesting is actually really hard, and the root of the
> problems tend to be graph traversals and path searches (for
> dependencies) not so much miscellaneous milliseconds spent in
> interpreter overhead.
>
> Then again, I suppose there will be people on computers slow enough
> where the latter does make a difference.
>
> > Put my time where my mouth is... Well I did, its called jem. What is
> > jem? Its java-config ported to C. I would be looking to port more of
> > Gentoo's tools to C for longevity and speed. Not speed of development,
> > but speed for everyone else. Instead I am doing C for other projects.
> >
> > 1. https://github.com/Obsidian-StudiosInc/jem
> >
> > P.S.
> > jem does need a bit more work to replace java-config entirely. Its
> > designed to not be Gentoo specific. There is little interest from
> > Gentoo, much less outside. Thus its more a case study than anything
> > benefiting anyone including myself. I will further it as I have
> > interest and time permits. Still have a few more defects to address.
> >
>
>

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

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Ciaran McCreesh]

On Mon, 10 Jul 2017 18:14:23 -0700
Raymond Jennings <shentino@gmail.com> wrote:
> If I may ask, does anyone have any profiling information one way or
> the other to shed light on the situation?

Paludis does complete dependency and unused package tracking for
everything by default. Any performance difficulties are
implementation-related, not a fundamental problem.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Tue, 11 Jul 2017 02:23:56 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Mon, 10 Jul 2017 18:14:23 -0700
> Raymond Jennings <shentino@gmail.com> wrote:
> > If I may ask, does anyone have any profiling information one way or
> > the other to shed light on the situation?  

There are profilers for python. Python devs can comment on such. I am
not sure about other things like looking for leaks etc. I was not able
to run python stuff through valgrind. At least I could not run
java-config through valgrind like I do with jem.

IMHO python all around is just not as robust and should not be used for
such purposes. There maybe ways to make it faster. For something with
the complexity, it should really be done in something more robust. Just
requires talent to make it such.

> Paludis does complete dependency and unused package tracking for
> everything by default. Any performance difficulties are
> implementation-related, not a fundamental problem.

I agree its a portage issue. Not saying anyone's code sucks or
discounting their efforts. Things do not have to be slow.

I mentioned this directly to some portage people in person a few years
ago during a meeting in Southern California... Around the time I put
jem on Github.

It is really hard to start over if/when that happens. Thus doing it
piece meal maybe easier. Though may still end up with spaghetti in the
end. Hopefully it runs fast and taste good :)

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 20:12:28 -0500
R0b0t1 <r030t1@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
> <wlt-ml@o-sinc.com> wrote:
>>
> > IMHO anyone complaining about time taking for dependency resolution
> > etc. They should spend THEIR time writing stuff in a real native
> > language for speed.
> >
> > The difference I see with jem[1] vs java-config, is ridiculous.
....
> > If aspects of portage were done in C or C++, or maybe even Go. There
> > would be substantial performance improvements. The existing python
> > code can remain. Python can load and call functions from C/C++ DSO.
> > And vice versa, calling Python code from C/C++. I would say C vs
> > C++ but that is up to others.
> >  
> 
> https://wiki.gentoo.org/wiki/Q_applets
> 
> What you're suggesting is actually really hard, and the root of the
> problems tend to be graph traversals and path searches (for
> dependencies) not so much miscellaneous milliseconds spent in
> interpreter overhead.

I am aware in a way. Depends on how implemented. This has to hit
package.env files. But what you see below comes from a dependency list.
I have packages with even more deps.

jem --help

 Package Options:
  -d, --with-dependencies    Include package dependencies in
                                        --classpath and --library calls
  -p, --classpath=PACKAGE(s) Print entries in the environment classpath
                                        for these packages

jem -d -p eclipse-jdt-core-4.6
/usr/share/ant-core/lib/ant.jar:/usr/share/ant-core/lib/ant-bootstrap.jar:/usr/share/ant-core/lib/ant-launcher.jar:/usr/share/eclipse-core-contenttype-4.6/lib/eclipse-core-contenttype.jar:/usr/share/eclipse-core-filesystem-4.6/lib/eclipse-core-filesystem.jar:/usr/share/eclipse-core-jobs-4.6/lib/eclipse-core-jobs.jar:/usr/share/eclipse-core-resources-4.6/lib/eclipse-core-resources.jar:/usr/share/eclipse-core-runtime-4.6/lib/eclipse-core-runtime.jar:/usr/share/eclipse-equinox-app-4.6/lib/eclipse-equinox-app.jar:/usr/share/eclipse-equinox-common-4.6/lib/eclipse-equinox-common.jar:/usr/share/eclipse-equinox-preferences-4.6/lib/eclipse-equinox-preferences.jar:/usr/share/eclipse-equinox-registry-4.6/lib/eclipse-equinox-registry.jar:/usr/share/eclipse-osgi-4.6/lib/eclipse-osgi.jar:/usr/share/eclipse-text-4.6/lib/eclipse-text.jar:/usr/share/osgi-core-api-6/lib/osgi-core-api.jar:/usr/share/eclipse-core-expressions-4.6/lib/eclipse-core-expressions.jar:/usr/share/osgi-compendium-6/lib/osgi-compendium.jar:/usr/share/eclipse-osgi-services-4.6/lib/eclipse-osgi-services.jar:/usr/share/osgi-annotation/lib/osgi-annotation.jar:/usr/share/felix-resolver/lib/felix-resolver.jar:/usr/share/eclipse-core-commands-4.6/lib/eclipse-core-commands.jar:/usr/share/icu4j-59/lib/icu4j.jar:/usr/share/glassfish-persistence/lib/glassfish-persistence.jar:/usr/share/osgi-foundation/lib/org.osgi.foundation.jar:/usr/share/tomcat-servlet-api-4.0/lib/el-api.jar:/usr/share/tomcat-servlet-api-4.0/lib/jsp-api.jar:/usr/share/tomcat-servlet-api-4.0/lib/servlet-api.jar:/usr/share/eclipse-jdt-core-4.6/lib/eclipse-jdt-core.jar

jem
real    0m0.004s
user    0m0.000s
sys     0m0.005s

java-config
real    0m0.075s
user    0m0.057s
sys     0m0.017s

On further runs of java-config
real    0m0.121s
user    0m0.105s
sys     0m0.017s

jem never exceeds 0m0.005s for any real, user, or sys

> Then again, I suppose there will be people on computers slow enough
> where the latter does make a difference.

arm? Laptops? Even if not speed, resources. But when its used for many
packages called over and over. It can start to add up little by little.
We can all use more time.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 9:29 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
>
> I am aware in a way. Depends on how implemented. This has to hit
> package.env files. But what you see below comes from a dependency list.
> I have packages with even more deps.
>

If you want to cope with poor package maintenance practices you might
also need to scan the entire repository to find packages which had a
dependency added after the package in question was installed.  I
forget if portage does this currently - I do remember this being the
topic of a fair bit of debate a while back.  I'm pretty sure failing
to revbump when dependencies are changed is considered a QA issue for
this reason.

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Tue, 11 Jul 2017 00:24:10 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> William, I'm not sure if you're aware of how package managers work but
> checking reverse dependencies of a package takes significant amount of
> time. Changing -C to do that would be a serious performance
> regression. Which would result in users requesting yet another option
> to disable this.

Eh, that's a Portage performance problem, not a package manager
performance problem.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Tue, 11 Jul 2017 02:09:12 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 11 Jul 2017 00:24:10 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > William, I'm not sure if you're aware of how package managers work
> > but checking reverse dependencies of a package takes significant
> > amount of time. Changing -C to do that would be a serious
> > performance regression. Which would result in users requesting yet
> > another option to disable this.  
> 
> Eh, that's a Portage performance problem, not a package manager
> performance problem.

I do recall years ago paludis being much faster, and providing more
detailed information on package slots, archs, etc. In a graph like
output if I recall. It was super useful in package maintenance. It
really helped with cleaning things safely!

Last I checked in out ~year or so, It was just to difficult to get to
work with portage. Paludis has changed considerably. Seems you need to
change a system to work with it. Not as use along side of portage as it
was in the past. It would be nice to be able to compare it side by side
to portage. Though I know it has some different features.

Need to check out pkgcore. Though I am not the one complaining about
time. Just saying for those who are...

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ulrich Mueller]

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

>>>>> On Mon, 10 Jul 2017, William L Thomson wrote:

> Stop getting lost in the weeds!!!!
> You all are making this about -c vs -C. I am not talking about that!

> LET ME CLARIFY....

> [...] SHOULD [...] PERIOD. NOTHING [...]

> So PLEASE stop with that!

Right. Please stop shouting in the gentoo-dev mailing list. Thank you.

Ulrich

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1042 bytes --]

On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler <bkohler@gmail.com> wrote:
>>
>> If you want dependencies checked, use the correct option which checks
>> them.  This takes significantly longer than -C, as it's significantly
>> more complex to check for.
>>
>> As far as I can tell, you are literally asking for -C to behave like
>> -c, when you could just be using -c instead.
> 
> No I simply want warnings like that exist for profiles and set packages.
> 
> Also more information when attempting to remove a package that is not
> removed.
> 

OK, well, as Ben said it's not feasible to make -C act like -c due to
the performance hit involved and due to the purpose of the command itself.

It likely is feasible and may well make sense to add a message to the
-c output that states that packages in the provided list aren't
removed because they are dependencies.  You should open up a bug for
that against portage and let the portage dev's sort it out.






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Mon, 10 Jul 2017 17:21:42 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 15:36:11 -0500
> > Ben Kohler <bkohler@gmail.com> wrote:  
> >>
> >> If you want dependencies checked, use the correct option which
> >> checks them.  This takes significantly longer than -C, as it's
> >> significantly more complex to check for.
> >>
> >> As far as I can tell, you are literally asking for -C to behave
> >> like -c, when you could just be using -c instead.  
> > 
> > No I simply want warnings like that exist for profiles and set
> > packages.
> > 
> > Also more information when attempting to remove a package that is
> > not removed.
> >   
> 
> OK, well, as Ben said it's not feasible to make -C act like -c due to
> the performance hit involved and due to the purpose of the command
> itself.

Have you profiled this? It shouldn't be slow if implemented correctly.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Mon, 10 Jul 2017 15:36:16 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
>
> !!! 'sys-devel/gcc' is part of your system profile.
> !!! Unmerging it may be damaging to your system.

When un-merging a package from a set, You get a similar warning. I
think this warning should also be generated for any package that is a
dependency. The user did not install that just like they did not
install directly the stuff in system or world. 

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

For everyone talking about -c vs -C. For the record, I never brought up
removing packages in my sets discussion. That was an argument others
were making against sets.

It was 2 others seen below who mentioned the use of -C/--unmerge. For
anyone telling me, I should be using -c vs -C. Why did you not say
anything to them? They brought it up? They were the ones using? Yet no
one spoke up to them as the have to me....

I was not discussing that. I rarely use such myself. I was just
entertaining a discussion with others, their issues. Just for others to
put the focus on me. It is all pretty funny!

On Sat, 8 Jul 2017 20:27:38 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> > On Fri, 7 Jul 2017 12:57:17 -0400
> > Brian Evans <grknight@gentoo.org> wrote:
> >   
> > Beware of sets.. if you put toolchain packages in a set and later
> > do 'emerge --unmerge @custom-set' , emerge will happily destroy
> > your toolchain.  
>
>   I tried "emerge -pv --unmerge @palemoon_build", and it was ready to
> delete all the stuff, including gcc, etc.

https://archives.gentoo.org/gentoo-dev/message/201cc1e7b5b878e3b28c3da1a41819e2
https://archives.gentoo.org/gentoo-dev/message/4ba8307a9dd5561cc1859a8c9546807a

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

For anyone interested in such, I opened a feature request bug for
allowing use of sets in profile packages. 

https://bugs.gentoo.org/show_bug.cgi?id=624300

P.S.
Miss posted on wrong thread... thus duplicate, sorry!

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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

On Sat, 8 Jul 2017 18:20:54 -0400
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> For anyone interested in such, I opened a feature request bug for
> allowing use of sets in profile packages. 
> 
> https://bugs.gentoo.org/show_bug.cgi?id=624300
> 

Subsequent bugs from the discussion

portage should not add system, world, profile, set, or dependent
packages to world, like -1/--oneshot
https://bugs.gentoo.org/show_bug.cgi?id=624628

Add warning message when -C/--unmerge a dependency like system,
profile, and set files.
https://bugs.gentoo.org/show_bug.cgi?id=624630

Thank you for all's input on this topic and related. This should
conclude the thread now, or at least my part. :)

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]