[gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

This was noticed recently when getting:
https://bugs.gentoo.org/show_bug.cgi?id=420569

Also hit this problem today while trying to bump bluez and noticed we
are using elog messages to tell people to manually install
net-dialup/ppp if they want ppp working with bluez.

I am unsure about the disadvantages of simply using, for example, "ppp"
USE flag to do that. One important disadvantage of current "elog message
way" is that:
1. We rely in people reading the message to get package working ok.
2. If user emerges ppp, it will be recorded in world file and, then, if
in the future he removes bluez, emerge --depclean want clean no longer
needed ppp and then, people end up with a lot of packages they needed to
manually emerge some year but that they problem no longer need at all.

Thanks for your thoughts

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[hasufell]

It breaks the useflag philosophy, IMO.

Useflags were meant as switches. You can turn things on and off. Pulling
in optional dependencies via useflags does not allow the user to turn
something off when he sets USE="-foo" emerge fuqbar.
That should only be valid for virtuals or meta-packages. And that's what
those are for.

It's not that important if there is a linkage IMO (like the devmanual
says), cause that may not apply to all languages/usecases, but it MUST
change what gets installed.

> 1. We rely in people reading the message to get package working ok.

Yes, we should rely on that.

> 2. If user emerges ppp, it will be recorded in world file and, then, if
> in the future he removes bluez, emerge --depclean want clean no longer
> needed ppp and then, people end up with a lot of packages they needed
> to manually emerge some year but that they problem no longer need at all.

It's not our job to maintain users world files.

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> It breaks the useflag philosophy, IMO.
> 
> Useflags were meant as switches. You can turn things on and off. Pulling
> in optional dependencies via useflags does not allow the user to turn
> something off when he sets USE="-foo" emerge fuqbar.
> That should only be valid for virtuals or meta-packages. And that's what
> those are for.
> 

Maybe we could split them from RDEPEND to some kind of EXTRA_DEPEND (or
something else) to fit this purpose.

> It's not that important if there is a linkage IMO (like the devmanual
> says), cause that may not apply to all languages/usecases, but it MUST
> change what gets installed.
> 
> > 1. We rely in people reading the message to get package working ok.
> 
> Yes, we should rely on that.

The problem of relying on that is, for example, following situation:
1. I install all my system without thinking on USB modems as I don't
have one.
2. Months after that, I need its support, but I need to figure out I
need to manually emerge sys-apps/usb_modeswitch to get it used by
modemmanager, as I don't rebuild  net-misc/modemmanager every day, I get
no notification at all to know I need to emerge that package.

> 
> > 2. If user emerges ppp, it will be recorded in world file and, then, if
> > in the future he removes bluez, emerge --depclean want clean no longer
> > needed ppp and then, people end up with a lot of packages they needed
> > to manually emerge some year but that they problem no longer need at all.
> 
> It's not our job to maintain users world files.
> 
> 

Even for me I tend to periodically check world files of machines I
maintain, and it's tedious, we shouldn't promote people to easily
contaminate their world files. Currently, most people will end up having
a lot of unneeded packages installed in their systems after years of
usage due this way of happily telling people to install some random
packages to get extra support.

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[hasufell]

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

On 06/16/2012 06:30 PM, Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
>> It breaks the useflag philosophy, IMO.
>> 
>> Useflags were meant as switches. You can turn things on and off.
>> Pulling in optional dependencies via useflags does not allow the
>> user to turn something off when he sets USE="-foo" emerge
>> fuqbar. That should only be valid for virtuals or meta-packages.
>> And that's what those are for.
>> 
> 
> Maybe we could split them from RDEPEND to some kind of EXTRA_DEPEND
> (or something else) to fit this purpose.

I would like the idea of having EXTRA_DEPEND which will then
automatically be elogged in pkg_postinst and maybe recorded in a
seperate file in /var/lib/portage?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP3Ld0AAoJEFpvPKfnPDWzzh0H/3kn12Yqrlw5h233CQjeVsZQ
ybaOrdBlszRuprevrLtPfphdRzJBuvUwrHzkL+fVm5ZLRUONC786mu17aYvkxlzj
3s0LsohDATnWWzItwlwMpJuuoeiy5rn7sZpnIkL6BF6sahh2feF+7hJyn9m2kw9l
L7qk8R1J2zEhgBo+zVdnwXVpqltm3rjR8pRjIvFtI+58VNfIt6HhM6fOIAupUaMU
URVeSBcb4sHJ2A3ByqDFePRDd4UHkwUI3tJRSULVqTah643zx4Q6MDEWVOAz9bit
F0lA+gSrBnJoMOImpVqBTfYRCDbIDuuShHYJlyUegO/MwY+PSyYdYCV6k3HZwek=
=SSoo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Michał Górny]

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

On Sat, 16 Jun 2012 18:30:55 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> > It breaks the useflag philosophy, IMO.
> > 
> > Useflags were meant as switches. You can turn things on and off.
> > Pulling in optional dependencies via useflags does not allow the
> > user to turn something off when he sets USE="-foo" emerge fuqbar.
> > That should only be valid for virtuals or meta-packages. And that's
> > what those are for.
> > 
> 
> Maybe we could split them from RDEPEND to some kind of EXTRA_DEPEND
> (or something else) to fit this purpose.

There was already a lot of discussion about this and the community
didn't care enough to agree on one of the proposed solutions. You're
just reinventing one of them, with a new variable name and the same
disadvantages.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió:
> On Sat, 16 Jun 2012 18:30:55 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> > > It breaks the useflag philosophy, IMO.
> > > 
> > > Useflags were meant as switches. You can turn things on and off.
> > > Pulling in optional dependencies via useflags does not allow the
> > > user to turn something off when he sets USE="-foo" emerge fuqbar.
> > > That should only be valid for virtuals or meta-packages. And that's
> > > what those are for.
> > > 
> > 
> > Maybe we could split them from RDEPEND to some kind of EXTRA_DEPEND
> > (or something else) to fit this purpose.
> 
> There was already a lot of discussion about this and the community
> didn't care enough to agree on one of the proposed solutions. You're
> just reinventing one of them, with a new variable name and the same
> disadvantages.
> 

Do you have a link to that old thread? Because current situation of
relying on elog messages also has disadvantages

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Michał Górny]

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

On Sat, 16 Jun 2012 20:49:10 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió:
> > On Sat, 16 Jun 2012 18:30:55 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> > > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> > > > It breaks the useflag philosophy, IMO.
> > > > 
> > > > Useflags were meant as switches. You can turn things on and off.
> > > > Pulling in optional dependencies via useflags does not allow the
> > > > user to turn something off when he sets USE="-foo" emerge
> > > > fuqbar. That should only be valid for virtuals or
> > > > meta-packages. And that's what those are for.
> > > > 
> > > 
> > > Maybe we could split them from RDEPEND to some kind of
> > > EXTRA_DEPEND (or something else) to fit this purpose.
> > 
> > There was already a lot of discussion about this and the community
> > didn't care enough to agree on one of the proposed solutions. You're
> > just reinventing one of them, with a new variable name and the same
> > disadvantages.
> > 
> 
> Do you have a link to that old thread? Because current situation of
> relying on elog messages also has disadvantages

http://thread.gmane.org/gmane.linux.gentoo.devel/71794
http://thread.gmane.org/gmane.linux.gentoo.devel/72162

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 22:36 +0200, Michał Górny escribió:
> On Sat, 16 Jun 2012 20:49:10 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió:
> > > On Sat, 16 Jun 2012 18:30:55 +0200
> > > Pacho Ramos <pacho@gentoo.org> wrote:
> > > 
> > > > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> > > > > It breaks the useflag philosophy, IMO.
> > > > > 
> > > > > Useflags were meant as switches. You can turn things on and off.
> > > > > Pulling in optional dependencies via useflags does not allow the
> > > > > user to turn something off when he sets USE="-foo" emerge
> > > > > fuqbar. That should only be valid for virtuals or
> > > > > meta-packages. And that's what those are for.
> > > > > 
> > > > 
> > > > Maybe we could split them from RDEPEND to some kind of
> > > > EXTRA_DEPEND (or something else) to fit this purpose.
> > > 
> > > There was already a lot of discussion about this and the community
> > > didn't care enough to agree on one of the proposed solutions. You're
> > > just reinventing one of them, with a new variable name and the same
> > > disadvantages.
> > > 
> > 
> > Do you have a link to that old thread? Because current situation of
> > relying on elog messages also has disadvantages
> 
> http://thread.gmane.org/gmane.linux.gentoo.devel/71794

Thanks :)

From this one looks like:
http://article.gmane.org/gmane.linux.gentoo.devel/71889
http://article.gmane.org/gmane.linux.gentoo.devel/71827

are interesting approaches. Personally, SDEPEND approach looks really
interesting to me, maybe it's only problem would be how to explain that
some extra packages are needed without requiring to elog, but looks like
exherbo already implements a solution for this. Other think I would like
to see in this approach is to add a way to *globally* configure PM to
always accept or discard extra deps by default (even still being able to
configure it per package as already suggested)

> http://thread.gmane.org/gmane.linux.gentoo.devel/72162
> 

If it's too difficult to implement first EAPI solution ok, but I really
would prefer the EAPI  way instead of using eclass to show more postinst
messages instead as I really prefer this to be handled in a more
automatic/configurable way. Also, only packages currently needing to use
elog messages for this kind of problem would need to be updated to
latest EAPI.


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

[gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Duncan]

Pacho Ramos posted on Sat, 16 Jun 2012 18:30:55 +0200 as excerpted:

>> > 2. If user emerges ppp, it will be recorded in world file and, then,
>> > if in the future he removes bluez, emerge --depclean want clean no
>> > longer needed ppp and then, people end up with a lot of packages they
>> > needed to manually emerge some year but that they problem no longer
>> > need at all.
>> 
>> It's not our job to maintain users world files.
>> 
>> 
>> 
> Even for me I tend to periodically check world files of machines I
> maintain, and it's tedious, we shouldn't promote people to easily
> contaminate their world files. Currently, most people will end up having
> a lot of unneeded packages installed in their systems after years of
> usage due this way of happily telling people to install some random
> packages to get extra support.

Looking at the broader picture, the problem of extraneous packages in the 
world file has always concerned me.  If it were to be done over again, 
and I think Zac would likely agree, emerge would use --oneshot by 
default, so as not to contaminate the world file unnecessarily.  Then 
there'd be a different option (say -2) to add the package to the world 
file if that's what was actually intended.

That's actually how I have my emerge front-end scriptlets/aliases setup 
here.  -1 is the default; if I want it in the world file I use the *2 
script variant, which omits the -1.

But of course changing behavior in mid-stream doesn't work so well, so 
emerge continues to stick stuff in the world file by default.


Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.  
Since I've been working with kde4 since it was overlay-only and sets-
only, no meta-packages, I've been using sets for quite awhile and it's 
now entirely integrated into how I work with portage.

When I setup my netbook on gentoo, I wanted most of the same setup as on 
my main machine, but with some differences, so I had to go thru the main 
machine's world file and pick and choose what I needed.

What I quickly realized is that my kde packages were already nicely 
categorized into sets, so all I really needed to do was split up the rest 
of the world file into a bunch of other sets, by category.  So for 
instance:

$>>cat /etc/portage/sets/jed.dev
dev-util/ccache
dev-util/desktop-file-utils
dev-vcs/git
sys-devel/bin86
sys-devel/gcc
sys-devel/gdb


I have 24 such sets including my (customized) kde sets.  All packages 
formerly listed in the world file are found in these sets, instead, and 
of course the sets are in turn listed in /var/lib/portage/world_sets.

My world file is normally entirely empty, tho I do use it occasionally 
for packages I haven't decided whether I want to keep or not, but want to 
protect from --depclean, which I run after each update.  So my world file 
serves as a kind of package purgatory, until I decide whether it's going 
to be a part of my normal system, or removed.

The sets, meanwhile, break the former world file down into much more 
manageable categorized chunks, each of which is short enough and 
categorized specifically enough that if a package is no longer needed, it 
immediately sticks out like a sore thumb, as it's not lost among the 
noise of hundreds of "twisty packages, all different". =:^)


While not a direct solution to the problem at hand, proper use of sets 
WILL and DOES dramatically ease gentoo world-package administration, 
going a long way toward eliminating crufty world lists simply by allowing 
them to be cut into nice little chunks that can be categorized in ways 
that make sense for an individual site, so the cruft sticks out like the 
sore thumb it can really be, and is thus easily found and removed.


Meanwhile, another bonus of sets is the extra protection it gives you if 
you try to emerge -C something in a sets file (as opposed to the world 
file itself). =:^)  Seeing that warning that the package is in a set and 
can't be directly unmerged is rather like seeing the warning that it's in 
@system, except that user sets are easier to directly manage, and it has 
saved my butt a couple times when I was really too sleepy to be adminning 
the system in the first place.  But it's easy enough to remove (or 
comment) that line from the set, if removal is really intended, and 
that's what would ultimately need to be done anyway, to prevent it 
getting remerged.


Unfortunately, it has begun to look like sets are where baselayout2 and 
openrc were for many years, "forever coming, never getting here", at 
least for stable or even unmasked into ~arch. =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Dale]

Duncan wrote:
>
> Looking at the broader picture, the problem of extraneous packages in the 
> world file has always concerned me.  If it were to be done over again, 
> and I think Zac would likely agree, emerge would use --oneshot by 
> default, so as not to contaminate the world file unnecessarily.  Then 
> there'd be a different option (say -2) to add the package to the world 
> file if that's what was actually intended.
>
> That's actually how I have my emerge front-end scriptlets/aliases setup 
> here.  -1 is the default; if I want it in the world file I use the *2 
> script variant, which omits the -1.
>
> But of course changing behavior in mid-stream doesn't work so well, so 
> emerge continues to stick stuff in the world file by default.
>

I added -1 to my make.conf a long time ago.  Whenever I emerge something
and want it in the world file, just use the --select option.  If I
already emerged something but then want to add it to the world file,
just add the -n option too.  That keeps the world file clean and I can
test things before adding anything to the world file. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 22:07 -0500, Dale escribió:
> Duncan wrote:
> >
> > Looking at the broader picture, the problem of extraneous packages in the 
> > world file has always concerned me.  If it were to be done over again, 
> > and I think Zac would likely agree, emerge would use --oneshot by 
> > default, so as not to contaminate the world file unnecessarily.  Then 
> > there'd be a different option (say -2) to add the package to the world 
> > file if that's what was actually intended.
> >
> > That's actually how I have my emerge front-end scriptlets/aliases setup 
> > here.  -1 is the default; if I want it in the world file I use the *2 
> > script variant, which omits the -1.
> >
> > But of course changing behavior in mid-stream doesn't work so well, so 
> > emerge continues to stick stuff in the world file by default.
> >
> 
> I added -1 to my make.conf a long time ago.  Whenever I emerge something
> and want it in the world file, just use the --select option.  If I
> already emerged something but then want to add it to the world file,
> just add the -n option too.  That keeps the world file clean and I can
> test things before adding anything to the world file. 
> 
> Dale
> 
> :-)  :-) 
> 

The problem is that this wouldn't solve the first issue because people
would still need to emerge extra packages with "--select" option if they
don't want to see them going away on next depclean round even if package
that needed them is still installed


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

Re: [gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Zac Medico]

On 06/16/2012 02:56 PM, Duncan wrote:
> Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.  
> Since I've been working with kde4 since it was overlay-only and sets-
> only, no meta-packages, I've been using sets for quite awhile and it's 
> now entirely integrated into how I work with portage.
> 
> When I setup my netbook on gentoo, I wanted most of the same setup as on 
> my main machine, but with some differences, so I had to go thru the main 
> machine's world file and pick and choose what I needed.
> 
> What I quickly realized is that my kde packages were already nicely 
> categorized into sets, so all I really needed to do was split up the rest 
> of the world file into a bunch of other sets, by category.  So for 
> instance:
> 
> $>>cat /etc/portage/sets/jed.dev
> dev-util/ccache
> dev-util/desktop-file-utils
> dev-vcs/git
> sys-devel/bin86
> sys-devel/gcc
> sys-devel/gdb
> 
> 
> I have 24 such sets including my (customized) kde sets.  All packages 
> formerly listed in the world file are found in these sets, instead, and 
> of course the sets are in turn listed in /var/lib/portage/world_sets.
> 
> My world file is normally entirely empty, tho I do use it occasionally 
> for packages I haven't decided whether I want to keep or not, but want to 
> protect from --depclean, which I run after each update.  So my world file 
> serves as a kind of package purgatory, until I decide whether it's going 
> to be a part of my normal system, or removed.
> 
> The sets, meanwhile, break the former world file down into much more 
> manageable categorized chunks, each of which is short enough and 
> categorized specifically enough that if a package is no longer needed, it 
> immediately sticks out like a sore thumb, as it's not lost among the 
> noise of hundreds of "twisty packages, all different". =:^)
> 
> 
> While not a direct solution to the problem at hand, proper use of sets 
> WILL and DOES dramatically ease gentoo world-package administration, 
> going a long way toward eliminating crufty world lists simply by allowing 
> them to be cut into nice little chunks that can be categorized in ways 
> that make sense for an individual site, so the cruft sticks out like the 
> sore thumb it can really be, and is thus easily found and removed.
> 
> 
> Meanwhile, another bonus of sets is the extra protection it gives you if 
> you try to emerge -C something in a sets file (as opposed to the world 
> file itself). =:^)  Seeing that warning that the package is in a set and 
> can't be directly unmerged is rather like seeing the warning that it's in 
> @system, except that user sets are easier to directly manage, and it has 
> saved my butt a couple times when I was really too sleepy to be adminning 
> the system in the first place.  But it's easy enough to remove (or 
> comment) that line from the set, if removal is really intended, and 
> that's what would ultimately need to be done anyway, to prevent it 
> getting remerged.
> 
> 
> Unfortunately, it has begun to look like sets are where baselayout2 and 
> openrc were for many years, "forever coming, never getting here", at 
> least for stable or even unmasked into ~arch. =:^(

Support for /etc/portage/sets is included in portage-2.1.11:

  https://bugs.gentoo.org/show_bug.cgi?id=384061
-- 
Thanks,
Zac

[gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Duncan]

Zac Medico posted on Sat, 23 Jun 2012 16:30:53 -0700 as excerpted:

> On 06/16/2012 02:56 PM, Duncan wrote:
>> Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.

>> Unfortunately, it has begun to look like sets are where baselayout2 and
>> openrc were for many years, "forever coming, never getting here", at
>> least for stable or even unmasked into ~arch. =:^(
> 
> Support for /etc/portage/sets is included in portage-2.1.11:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=384061


Hallelujah!  I see from the bug comments that it just landed, too.  
Thanks!


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Peter Stuge]

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

Pacho Ramos wrote:
> Also hit this problem today while trying to bump bluez and noticed we
> are using elog messages to tell people to manually install
> net-dialup/ppp if they want ppp working with bluez.
> 
> I am unsure about the disadvantages of simply using, for example,
> "ppp" USE flag to do that.

I guess the point is that it is not really a dependency. bluez works
fine without ppp, it does not need to be rebuilt to use ppp later,
and ppp is only needed when user wants to use both together.

I think it fits to emerge them separately. It seems reasonable not to
USE for other packages which are merely possible to combine, but
which don't make for a strict dependency.


> 1. We rely in people reading the message to get package working ok.

I dunno if a USE flag is much better? Both require the user to inform
herself in the same way ("when do I need USE=ppp for bluez" vs. "when
do I need to emerge ppp") and take action in the same context (set
USE=ppp for bluez vs. emerge ppp after bluez)..


> 2. If user emerges ppp, it will be recorded in world file and, then, if
> in the future he removes bluez, emerge --depclean want clean no longer
> needed ppp and then, people end up with a lot of packages they needed
> to manually emerge some year but that they problem no longer need at
> all.

Disk is pretty cheap. If the package is never being used and the user
doesn't care to remove it then the package doesn't do any harm IMO,
and as mentioned I think it's difficult for the package manager to
know what the user has installed on the system but no longer needs..


//Peter

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 19:50 +0200, Peter Stuge escribió:
> Pacho Ramos wrote:
> > Also hit this problem today while trying to bump bluez and noticed we
> > are using elog messages to tell people to manually install
> > net-dialup/ppp if they want ppp working with bluez.
> > 
> > I am unsure about the disadvantages of simply using, for example,
> > "ppp" USE flag to do that.
> 
> I guess the point is that it is not really a dependency. bluez works
> fine without ppp, it does not need to be rebuilt to use ppp later,
> and ppp is only needed when user wants to use both together.
> 

No, it's a dependency only when you want ppp support working, if you
won't use it, you won't simply notice it won't work due missing
dependency

> I think it fits to emerge them separately. It seems reasonable not to
> USE for other packages which are merely possible to combine, but
> which don't make for a strict dependency.
> 
> 
> > 1. We rely in people reading the message to get package working ok.
> 
> I dunno if a USE flag is much better? Both require the user to inform
> herself in the same way ("when do I need USE=ppp for bluez" vs. "when
> do I need to emerge ppp") and take action in the same context (set
> USE=ppp for bluez vs. emerge ppp after bluez)..
> 
> 

It's much easier to widely set "ppp" USE in make.conf to be sure ppp
support works for all things in my system that needing to rebuild
affected package to see elog message telling me that I need to manually
emerge some other package

> > 2. If user emerges ppp, it will be recorded in world file and, then, if
> > in the future he removes bluez, emerge --depclean want clean no longer
> > needed ppp and then, people end up with a lot of packages they needed
> > to manually emerge some year but that they problem no longer need at
> > all.
> 
> Disk is pretty cheap. If the package is never being used and the user
> doesn't care to remove it then the package doesn't do any harm IMO,
> and as mentioned I think it's difficult for the package manager to
> know what the user has installed on the system but no longer needs..
> 
> 
> //Peter

What kind of argument is "disk is pretty cheap". I still administrate a
laptop with a 250GB of disk space, and that space cannot be as large if
you have a lot of files at home. Also, you are missing that having
unneeded packages in world file will also cause them to be updated on
every system updated, with the time it takes for compile.


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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Peter Stuge]

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

Pacho Ramos wrote:
> > I guess the point is that it is not really a dependency.
> 
> No, it's a dependency only when you want ppp support working,

Logically, but not technically.

I like this separation; the package manager takes care of technical
requirements, and I get to take care of the logical requirements.


> > I dunno if a USE flag is much better? Both require the user to inform
> > herself in the same way ("when do I need USE=ppp for bluez" vs. "when
> > do I need to emerge ppp")
> 
> It's much easier to widely set "ppp" USE in make.conf to be sure ppp
> support works for all things in my system that needing to rebuild
> affected package to see elog message telling me that I need to manually
> emerge some other package

My point is that when you know that you need ppp (and how could you
set USE=ppp otherwise) then it is about equally easy to emerge ppp
as it is to set USE=ppp.


> > > people end up with a lot of packages they needed to manually
> > > emerge some year but that they problem no longer need at all.
> > 
> > Disk is pretty cheap. If the package is never being used and the user
> > doesn't care to remove it then the package doesn't do any harm IMO,
> > and as mentioned I think it's difficult for the package manager to
> > know what the user has installed on the system but no longer needs..
> 
> What kind of argument is "disk is pretty cheap".

Please read the rest of what I wrote too. :)


> I still administrate a laptop with a 250GB of disk space, and that
> space cannot be as large if you have a lot of files at home.

My primary system had 8GB storage until a few years ago when flash
prices went down. I was motivated to keep my system clean. If one is
space constrained then I think one naturally pays more attention to
keeping world small. Disk is still cheap. If it is a problem for me
that I have unneeded packages installed, *then* I will start looking
at cleaning up. Until then, there's no problem.


> Also, you are missing that having unneeded packages in world file
> will also cause them to be updated on every system updated, with
> the time it takes for compile.

I'm not missing, but I'm saying that it is merely the effect of not
managing world very actively.

I think it's difficult to impossible for a package manager to
reliably determine logical requirements from what is a model
(USE flags) of technical requirements (link-time dependencies).


//Peter

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 22:10 +0200, Peter Stuge escribió:
> Pacho Ramos wrote:
> > > I guess the point is that it is not really a dependency.
> > 
> > No, it's a dependency only when you want ppp support working,
> 
> Logically, but not technically.
> 
> I like this separation; the package manager takes care of technical
> requirements, and I get to take care of the logical requirements.
> 
> 
> > > I dunno if a USE flag is much better? Both require the user to inform
> > > herself in the same way ("when do I need USE=ppp for bluez" vs. "when
> > > do I need to emerge ppp")
> > 
> > It's much easier to widely set "ppp" USE in make.conf to be sure ppp
> > support works for all things in my system that needing to rebuild
> > affected package to see elog message telling me that I need to manually
> > emerge some other package
> 
> My point is that when you know that you need ppp (and how could you
> set USE=ppp otherwise) then it is about equally easy to emerge ppp
> as it is to set USE=ppp.

But that point is valid with this exact example because, in this case,
it's really intuitive to do so, but in other cases in the tree, there is
not such good liaison between USE flag name and needed package ;)
 
> 
> 
> > > > people end up with a lot of packages they needed to manually
> > > > emerge some year but that they problem no longer need at all.
> > > 
> > > Disk is pretty cheap. If the package is never being used and the user
> > > doesn't care to remove it then the package doesn't do any harm IMO,
> > > and as mentioned I think it's difficult for the package manager to
> > > know what the user has installed on the system but no longer needs..
> > 
> > What kind of argument is "disk is pretty cheap".
> 
> Please read the rest of what I wrote too. :)
> 
> 
> > I still administrate a laptop with a 250GB of disk space, and that
> > space cannot be as large if you have a lot of files at home.
> 
> My primary system had 8GB storage until a few years ago when flash
> prices went down. I was motivated to keep my system clean. If one is
> space constrained then I think one naturally pays more attention to
> keeping world small. Disk is still cheap. If it is a problem for me
> that I have unneeded packages installed, *then* I will start looking
> at cleaning up. Until then, there's no problem.
> 
> 
> > Also, you are missing that having unneeded packages in world file
> > will also cause them to be updated on every system updated, with
> > the time it takes for compile.
> 
> I'm not missing, but I'm saying that it is merely the effect of not
> managing world very actively.
> 
> I think it's difficult to impossible for a package manager to
> reliably determine logical requirements from what is a model
> (USE flags) of technical requirements (link-time dependencies).
> 
> 
> //Peter

Well, looks like a solution for this is already implemented in exherbo
and there were also similar solutions proposed in the past, lets see if
we can agree on witch one would be better for us :)

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

[gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Duncan]

Pacho Ramos posted on Sat, 16 Jun 2012 20:52:33 +0200 as excerpted:

> What kind of argument is "disk is pretty cheap". I still administrate a
> laptop with a 250GB of disk space, and that space cannot be as large if
> you have a lot of files at home. Also, you are missing that having
> unneeded packages in world file will also cause them to be updated on
> every system updated, with the time it takes for compile.

Heh, and then there's netbooks.  I got one of the first with a real sata-
based connector and a 120 gig hard drive.  Sure, I could replace it now, 
and may well do so some day, but the 120 gig works fine for what I need 
ATM.  But of course many of the first netbooks had 2, 4, 8, 16 gig SSDs.  
That's REALLY tight, even if you're doing the actual builds in a build-
image on a different system and just rsyncing, so no portage tree, etc.

Meanwhile, very good point on the continual updates.  It's just that cost 
that encourages gentoo users, over time, to trim down to the package set 
they actually use.  In this context, that certainly means users would 
unmerge ppp if they knew about it when they no longer needed it, but 
knowing about it is the problem.  (Of course here I've solved that using 
sets as discussed in a different reply, but they're not yet available to 
the stable gentooer, and the way it looks, may remain that way for 
years...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Peter Stuge]

Duncan wrote:
> users would unmerge ppp if they knew about it when they no longer
> needed it, but knowing about it is the problem.

Sorry, but what is the connection to a USE flag?

I agree that knowing about it is the problem. I don't think that
knowing about a package is different from knowing about a USE flag.

Sets look nice though! :)


//Peter

[gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Duncan]

Peter Stuge posted on Sun, 17 Jun 2012 00:16:36 +0200 as excerpted:

> Duncan wrote:
>> users would unmerge ppp if they knew about it when they no longer
>> needed it, but knowing about it is the problem.
> 
> Sorry, but what is the connection to a USE flag?
> 
> I agree that knowing about it is the problem. I don't think that knowing
> about a package is different from knowing about a USE flag.

USE flags show up (with the recommended -v anyway) pre-merge, where 
people can see and deal with them (doing equery u <pkg> or whatever if 
they need more information about the flag) upfront.

post-pkg-install messages appear at the tail end, and even for people 
like me that are quite religious about reading such things, if a big 
system update crashes the entire system (I've been dealing with hardware 
issues lately so this is fresh in mind), messages for already merged at 
time of crash packages won't be shown when a new update is run after 
reboot.

So USE flags tend to be much more visible/discoverable. =:^)

> Sets look nice though! :)

I just wish whatever PMS or other issues would get worked out, so the 
feature could start benefiting normal users, not just those brave enough 
to run a masked portage. =:^(  I've been using sets since kde 4.2 when I 
migrated to kde4 at least, three years ago now, without major issue 
(there was a minor issue when certain sets parameters changed a year or 
two ago, but that's par for the course when using experimental features), 
and the technology really is reasonably mature and proven now.  It just 
needs to be available for ordinary gentooers...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Samuli Suominen]

On 06/16/2012 06:59 PM, Pacho Ramos wrote:
> This was noticed recently when getting:
> https://bugs.gentoo.org/show_bug.cgi?id=420569
>
> Also hit this problem today while trying to bump bluez and noticed we
> are using elog messages to tell people to manually install
> net-dialup/ppp if they want ppp working with bluez.
>
> I am unsure about the disadvantages of simply using, for example, "ppp"
> USE flag to do that. One important disadvantage of current "elog message
> way" is that:
> 1. We rely in people reading the message to get package working ok.
> 2. If user emerges ppp, it will be recorded in world file and, then, if
> in the future he removes bluez, emerge --depclean want clean no longer
> needed ppp and then, people end up with a lot of packages they needed to
> manually emerge some year but that they problem no longer need at all.
>
> Thanks for your thoughts
>

why not get this finally entirely out of the way:

suggested/recommended dependencies support, like SDEPEND, 
http://bugs.gentoo.org/327701

as in, threat them as RDEPEND if user has the option to pull them in 
enabled, otherwise print an uniformed postinst message

as a bonus, this solution would also allow USE dependencies to work and 
would replace some cases of 'has_version foo/bar[use]'

- Samuli

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[hasufell]

On 06/16/2012 07:55 PM, Samuli Suominen wrote:
> 
> why not get this finally entirely out of the way:
> 
> suggested/recommended dependencies support, like SDEPEND,
> http://bugs.gentoo.org/327701
> 
> as in, threat them as RDEPEND if user has the option to pull them in
> enabled, otherwise print an uniformed postinst message
> 
> as a bonus, this solution would also allow USE dependencies to work and
> would replace some cases of 'has_version foo/bar[use]'
> 
> - Samuli
> 

Sounds interesting, but I don't fully understand. Can you give an
example ebuild?

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Ciaran McCreesh]

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

On Sat, 16 Jun 2012 20:06:17 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 06/16/2012 07:55 PM, Samuli Suominen wrote:
> > why not get this finally entirely out of the way:
> > 
> > suggested/recommended dependencies support, like SDEPEND,
> > http://bugs.gentoo.org/327701
> >
> Sounds interesting, but I don't fully understand. Can you give an
> example ebuild?

Suggested dependencies were used in the old kdebuilds, and Exherbo
makes extensive use of both suggested and recommended dependencies, so
there are plenty of examples, spec wording and an implementation already
if you want to play.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[hasufell]

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

On 06/16/2012 08:14 PM, Ciaran McCreesh wrote:
> Suggested dependencies were used in the old kdebuilds, and Exherbo 
> makes extensive use of both suggested and recommended dependencies,
> so there are plenty of examples, spec wording and an implementation
> already if you want to play.
> 

I don't want to install Exherbo to see an example. Archlinux also has
a nice implementation about optional dependencies and I don't care
about that either.

This is about a gentoo specific implementation and I am still not
clear about how that proposed SDEPEND would look like.
Are useflags allowed for those too? How do I "activate" it? Via a
seperate config file in /etc/portage, is it a FEATURE? what what what
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP3TRMAAoJEFpvPKfnPDWz2acH+gKVpIutTnH62E8TwKvpB9mm
eiSaYkS+a4EowjZrDmu2DnBFFmbh+iXlZ+1RYeb+UYRI/r4AV+l24m/USbfOPxq8
ftHXNXH17K7Bl7hnxC2llhU+PHH6QEBAuh5Y7gIzLZL4G1IX92JNHm+noo6UHBBm
dsKFQJP4Mz2dzt3AvclT199HCxyggVALg7TkHhoZpT3g7clqdDeFRbUSya0nmAMq
vsysBHC6BlhaV5FcYUO+8o54qV65tRvwYXABL3vS7xmHm1QzT01gZkXCeehHAQ9b
CW4UWWfyJwk1SK50ZNrjzCiKfK8yVMhQgnaXy9357gX0Rk2AAITgtzeSz378kP0=
=wm7w
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Ciaran McCreesh]

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

On Sun, 17 Jun 2012 03:35:08 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 06/16/2012 08:14 PM, Ciaran McCreesh wrote:
> > Suggested dependencies were used in the old kdebuilds, and Exherbo 
> > makes extensive use of both suggested and recommended dependencies,
> > so there are plenty of examples, spec wording and an implementation
> > already if you want to play.
> 
> I don't want to install Exherbo to see an example. Archlinux also has
> a nice implementation about optional dependencies and I don't care
> about that either.
> 
> This is about a gentoo specific implementation and I am still not
> clear about how that proposed SDEPEND would look like.
> Are useflags allowed for those too? How do I "activate" it? Via a
> seperate config file in /etc/portage, is it a FEATURE? what what what

Surely being able to use it and play around with it for real is better
than seeing some not very helpful textual examples pasted in... Anyway,
you can probably find the old kdebuilds somewhere, those run on Gentoo.
For that matter, the Paludis ebuild in the overlay makes use of
suggestions, although it's only for one small set of things.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk/dyD0ACgkQ96zL6DUtXhFrUgCgkxzRAgqaDf6Al1/Zp9n7wRJL
pRYAoOBw7143Mch81VvBVsK3Us0FilRM
=JGNo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Pacho Ramos]

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

El sáb, 16-06-2012 a las 20:55 +0300, Samuli Suominen escribió:
> On 06/16/2012 06:59 PM, Pacho Ramos wrote:
> > This was noticed recently when getting:
> > https://bugs.gentoo.org/show_bug.cgi?id=420569
> >
> > Also hit this problem today while trying to bump bluez and noticed we
> > are using elog messages to tell people to manually install
> > net-dialup/ppp if they want ppp working with bluez.
> >
> > I am unsure about the disadvantages of simply using, for example, "ppp"
> > USE flag to do that. One important disadvantage of current "elog message
> > way" is that:
> > 1. We rely in people reading the message to get package working ok.
> > 2. If user emerges ppp, it will be recorded in world file and, then, if
> > in the future he removes bluez, emerge --depclean want clean no longer
> > needed ppp and then, people end up with a lot of packages they needed to
> > manually emerge some year but that they problem no longer need at all.
> >
> > Thanks for your thoughts
> >
> 
> why not get this finally entirely out of the way:
> 
> suggested/recommended dependencies support, like SDEPEND, 
> http://bugs.gentoo.org/327701
> 
> as in, threat them as RDEPEND if user has the option to pull them in 
> enabled, otherwise print an uniformed postinst message
> 
> as a bonus, this solution would also allow USE dependencies to work and 
> would replace some cases of 'has_version foo/bar[use]'
> 
> - Samuli
> 
> 

Looks fine to me, this must be the previous solution referred by mgorny,
but fail to see any comment there about that disadvantages that this
solution could have :/

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