Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Sat, 8 Jul 2017 18:20:54 -0400
"William L. Thomson Jr."  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.


pgp9kxXmMa3WO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ulrich Mueller]

> 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


pgpasY5wKD6yJ.pgp
Description: PGP signature

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 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Tue, 11 Jul 2017 02:09:12 +0100
Ciaran McCreesh  wrote:

> On Tue, 11 Jul 2017 00:24:10 +0200
> Michał Górny  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.


pgp78rFL5QpTN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Mon, 10 Jul 2017 17:21:42 -0400
Ian Stakenvicius  wrote:
> On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 15:36:11 -0500
> > Ben Kohler  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

[Ciaran McCreesh]

On Tue, 11 Jul 2017 00:24:10 +0200
Michał Górny  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.]

On Mon, 10 Jul 2017 17:08:54 -0500
Ben Kohler  wrote:

> On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr.
>  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.


pgpOj7xSdj0TL.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Michał Górny]

On pon, 2017-07-10 at 17:47 -0500, Gordon Pettey wrote:
> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny  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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Sets vs Meta ebuilds

[Gordon Pettey]

On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny  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.

Re: [gentoo-dev] Sets vs Meta ebuilds

[Michał Górny]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr. 
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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 16:30:07 -0400
Rich Freeman  wrote:

> On Mon, Jul 10, 2017 at 4:27 PM, William L. Thomson Jr.
>  wrote:
> > On Mon, 10 Jul 2017 15:55:47 -0400
> > Rich Freeman  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.


pgpcg5sIKTB6H.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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.


pgpi_CzwT3CNO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ian Stakenvicius]

On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler  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.







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:47 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler  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.]

On Mon, 10 Jul 2017 15:36:11 -0500
Ben Kohler  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.


pgpt1MIMOOMfm.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 3:27 PM, William L. Thomson Jr. 
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

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:27 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 15:55:47 -0400
> Rich Freeman  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.]

On Mon, 10 Jul 2017 15:55:47 -0400
Rich Freeman  wrote:

> On Mon, Jul 10, 2017 at 3:45 PM, William L. Thomson Jr.
>  wrote:
> > On Mon, 10 Jul 2017 14:39:00 -0500
> > Ben Kohler  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.


pgpKDGzv060YD.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 3:45 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 14:39:00 -0500
> Ben Kohler  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.]

On Mon, 10 Jul 2017 14:48:23 -0500
Ben Kohler  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.


pgpLCnqsGksgh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 14:39:00 -0500
Ben Kohler  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.


pgp5TMEgVbvWZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:36:16 -0400
"William L. Thomson Jr."  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.


pgpj1ngGoccKq.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 2:36 PM, William L. Thomson Jr. 
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 ` 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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 14:28:29 -0500
Ben Kohler  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 ` 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.


pgpikSlzOPh3U.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 2:25 PM, William L. Thomson Jr. 
wrote:

> On Mon, 10 Jul 2017 15:15:35 -0400
> "William L. Thomson Jr."  wrote:
>
> > # emerge -pC tomcat-servlet-api
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` 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

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:15:35 -0400
"William L. Thomson Jr."  wrote:

> # emerge -pC tomcat-servlet-api
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean ` 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.


pgpAw4WF9kSZ8.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:07:37 -0400
Brian Evans  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."  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 '.
> 
> 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 ` 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.


pgpOTZDJEqJTG.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

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."  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 '.

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

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 00:43:11 -0400
"William L. Thomson Jr."  wrote:

> On Sun, 9 Jul 2017 21:37:11 -0400
> "Walter Dnes"  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.


pgpjEI0mpc_KR.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Sun, 9 Jul 2017 21:37:11 -0400
"Walter Dnes"  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.


pgp9xkAQQUKvV.pgp
Description: OpenPGP digital signature

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"  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 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Sun, 9 Jul 2017 05:24:19 -0400
"Walter Dnes"  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"  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.


pgpHw5jp3Ev2c.pgp
Description: OpenPGP digital signature

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 
I don't run "desktop environments"; I run useful applications

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"  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 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Sat, 8 Jul 2017 20:27:38 -0400
"Walter Dnes"  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.


pgpBF_KcKMHrU.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Sat, Jul 8, 2017 at 8:27 PM, Walter Dnes  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 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  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  gtk seems to add more and more GNOME
dependencies every time I update my system. 

  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 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

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.


pgpkQZ6BpgeJj.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Fri, 7 Jul 2017 21:43:14 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Jul 2017 21:38:31 +0100
> James Le Cuirot  wrote:
> > On Fri, 7 Jul 2017 12:48:04 -0400
> > NP-Hardass  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.


pgpb6BTYnmChX.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Fri, 7 Jul 2017 21:38:31 +0100
James Le Cuirot  wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass  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

[NP-Hardass]

On 07/07/2017 04:38 PM, James Le Cuirot wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass  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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[James Le Cuirot]

On Fri, 7 Jul 2017 12:48:04 -0400
NP-Hardass  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


pgpplbLJbE9bC.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Fri, 7 Jul 2017 13:31:52 -0400
NP-Hardass  wrote:

> On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> > On Fri, 7 Jul 2017 12:48:04 -0400
> > NP-Hardass  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.


pgp9UFoEF0bdu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass  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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Fri, 7 Jul 2017 12:57:17 -0400
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.

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.


pgpF49FxZMPDD.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Fri, 7 Jul 2017 12:48:04 -0400
NP-Hardass  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.


pgpDmJSAHVTYl.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Fri, 7 Jul 2017 12:36:16 -0400
Lucas Ramage  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.


pgpD1D0rSunhu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Lucas Ramage]

Is that your blog?

On Fri, Jul 7, 2017 at 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.
>
> --
> William L. Thomson Jr.
>



-- 

Regards,

[image: View my Portfolio] 

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

Visit online journal
lramage94.github.io

[image: Google Plus]  [image:
Linkedin]