Re: [gentoo-dev] [PATCH 1/2] php-ext-source-r3.eclass: new revision supporting EAPI=6.

[Michael Orlitzky]

Thanks for the detailed review. I followed every suggestion except the
doexe thing for *.so files (only because I don't understand the
reasoning yet). The new version is attached.



On 06/01/2016 01:47 PM, Michał Górny wrote:
>> +DEPEND=">=sys-devel/m4-1.4.3  
>> +>=sys-devel/libtool-1.5.18"
>> +RDEPEND=""
> 
> Please move all of this below EAPI check. And I think *DEPEND would be
> better set in one place.

I moved them all after the REQUIRED_USE mess.


>> +case ${EAPI} in
>> +6) ;;
>> +*)
>> +die "php-ext-source-r3 is not compatible with EAPI=${EAPI}"
> 
> I think you can use ${ECLASS} here btw.

Done.


>> +# @DESCRIPTION:
>> +# Lists the PHP slots compatibile the extension is compatibile with
> 
> typo: compatible, and also appears twice ;-).

Fixed.


>> +# @ECLASS-VARIABLE: PHP_EXT_SAPIS
>> +# @DESCRIPTION:
>> +# A list of SAPIs for which we'll install this extension. Formerly
>> +# called PHPSAPILIST.
>> +[[ -z "${PHP_EXT_SAPIS}" ]] && PHP_EXT_SAPIS="apache2 cli cgi fpm embed 
>> phpdbg"
> 
> Is this default something that might get extended in the future? I
> think it might be worth noting that here.

Yeah, I think we'll keep every SAPI currently used in the tree in the
list by default. We added "phpdbg" even though php:5.5 doesn't support
it. I documented that.


>> +# Make sure at least one target is installed. First, start a USE
>> +# conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
>> +# non-null. The option group "|| (..." is always started here.
>> +REQUIRED_USE="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }|| ( "
>> +for target in ${USE_PHP}; do
> 
> Environment pollution! unset target, or make this local.

I renamed it to _php_target and unset it after the loop.


>> +# Now loop through each USE_PHP target and add the corresponding
>> +# dev-lang/php slot to PHPDEPEND.
>> +IUSE="${IUSE} php_targets_${target}"
> 
> Any reason not to use += here as well?

Nope, and likewise with PHPDEPEND in the same loop. I changed them both.


>> +# @ECLASS-VARIABLE: PHP_EXT_EXTRA_ECONF
>> +# @DESCRIPTION:
>> +# Set this in the ebuild to pass configure options to econf. Formerly
>> +# called my_conf.
> 
> Please don't name this *EXTRA_ECONF. EXTRA_ECONF is a Portage variable
> that's meant to be set by user in make.conf/env, and not ebuilds.

It's PHP_EXT_ECONF_ARGS now, and I updated the migration guide.


>> +# Let's put the default module away. Strip $EPREFIX from
>> +# $EXT_DIR before calling newins (which handles EPREFIX itself).
>> +insinto "${EXT_DIR#$EPREFIX}"
>> +newins "modules/${PHP_EXT_NAME}.so" "${PHP_EXT_NAME}.so"
> 
> Wouldn't it be more appropriate to use exeinto/doexe to have the shared
> libs +x?

I'd never heard this before... why? I suppose the only trade-off is that
having them -x prevents them from showing up in bash's tab-completion
for executables.


>> +# @FUNCTION: php_init_slot_env
>> +# @DESCRIPTION:
>> +# Takes a slot name, and initializes some global variables to values
>> +# corresponding to that slot. For example, it sets the path to the "php"
>> +# and "phpize" binaries, which will differ for each slot. This function
>> +# is intended to be called while looping through a list of slots
>> +# obtained from php_get_slots().
> 
> Please make it explicit that it changes working directory.

Done.


>> +# @FUNCTION: php_slot_ini_files
>> +# @INTERNAL
>> +# @DESCRIPTION:
>> +# Output a list of relative paths to INI files for the given
>> +# slot. Usually there will be one INI file per SAPI.
> 
> Please add @USAGE to make clear what ${1} is. In fact, many functions
> seem to miss @USAGE.

I added USAGE for every function that takes an argument. I also figured
out where the eclass manpages come from and made sure that the other doc
issues (like DEFAULT_UNSET) are fixed w.r.t. eclass-to-manpage.sh.


>> +cat "${FILESDIR}/${PHP_EXT_INIFILE}" >> 
>> "${ED}/${file}"
> 
> || die

Fixed all of these.


>> +# Add support for installing PHP files into a version dependent
>> +# directory
>> +PHP_EXT_SHARED_DIR="${EPREFIX}/usr/share/php/${PHP_EXT_NAME}"
> 
> Should this be repeated inside the loop?

There's a longer answer to that question, but the fact that it's outside
of the loop is intentional and consistent with -r2.


>> +php-ext-source-r3_addextension() {
>> +if [[ "${PHP_EXT_ZENDEXT}" = "yes" ]] ; then
>> +ext_type="zend_extension"
>> +ext_file="${EXT_DIR}/${1}" # Zend extensions need the path...
>> +else
>> +ext_type="extension"
>> +ext_file="${1}"
>> +fi
> 
> I think you want those variables local.

Fixed all of the local variable issues.


>> +php-ext-source-r3_addtoinifile() {
>> +local inifile="${WORKDIR}/${1}"
>> +local inidir="$(dirname ${inifile})"
> 
> I would suggest avoiding external tools like dirname when simple bash
> subst can do

Re: [gentoo-dev] [RFC] Global USE=gui

[Damien Levac]

On 2016-06-01 10:13 PM, waltd...@waltdnes.org wrote:

On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote


waltd...@waltdnes.org wrote:


   I see this as at least a redundancy, if not a problem.  First, let's
look at the general case.  An optional "UI" (User Interface) is also
selected...
* via the "tools" useflag 78 times in use.local.desc
* via the "ncurses" useflag 10 times in use.local.desc.
* for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
   does "ncurses" show up in use.local.desc ???)

  There is no need for an additional "TUI" (Text User Interface) use flag
for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
"GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
thing they have in common is a hard-coded dependancy on graphics libs.
"GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
Using any of them tells you enough.  What do we accomplish by requiring
one more USE flag?  This will also make dependancy resolution of ebuilds
more complex, i.e. slower.  Why?

Simple regular users don't want to be concerned with choice of toolkit
for every single package, as long as a GUI is provided.

   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
make.conf.  This will *FORCE* a gui where applicable.


Furthermore, this matches the recommended USE flag design where the
more important flags are provided as feature flags, while specific
dependency choice flags are minor.

   This is going to require *THREE* levels of flags, with the first one
being totally unnecessary...

Level 1) GUI

Level 2) X or xorg or Wayland or Mir

Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
   Let me re-phrase my question... is there *ANY* set of circumstances
under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
can be set for a package *WITHOUT* requiring a gui?  I can see any of X
or xorg or Wayland or Mir being a requirement for any of
qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
a GUI of one sort or another.
IMHO, you see this in reverse. the 'gui' useflag would be useful for 
users who don't want to care about X/wayland/mir and do not want to care 
about gtk/qt, they just want windows to be drawn for the applications 
they install -- without, if possible, pulling useless dependencies.


   I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
people ideas the wrong way.  No I don't want a "TUI" flag either.

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote:
> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> 
>> waltd...@waltdnes.org wrote:
>>
>>>   I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>   does "ncurses" show up in use.local.desc ???)
>>>
>>>  There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>>
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
> 
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
> 


The whole point of USE=gui is to get away from needing to do that.
Those flags should be used to choose -which- gui toolkit users want
when one is available, not to choose IF a gui should be built or not.
Take my example into account, i don't want anything qt based if I can
avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
not going to set that globally though because I don't want to choose
qt4 based front-ends for anything else, and having to guess for every
random package when i don't care so that I can set a package.use entry
for it is annoying.


>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
> 
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
> 
> Level 1) GUI
> 
> Level 2) X or xorg or Wayland or Mir
> 
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk


1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
needed.

2 - If X or Wayland or Mir support is available in a package, then yes
-- also i don't see a way that we don't need these.

3 - toolkit selection choices when a package supports multiple (but
only chooses one) is also a yes.  AND, because we're not tying any-gui
to one of these flags it means that users are free to set just the one
variant that they prefer, globally, instead of having to mess about
per-package.  It also means we can get rid of any or all of these
particular flags from profiles (except for 'gnome' or 'plasma' or the
desktop-variant-specific ones).

The point here is that if there's an app (say, wpa_supplicant as
mentioned before) that provides a gui tool but no options as to what
that tool needs in terms of toolkit etc, we can -just- have USE=gui
control whether or not it's built.  It'll pull in qt because qt is
what it needs, and if someone is dead set against having qt in their
system then they'll know from the dependency tree.  There's no need to
peg the individual toolkit to packages like this just to enable a gui.


> 
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.


Likely there is but I'd need to search.  Extending libraries mostly --
cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[james]

On 06/01/2016 06:20 PM, Justin Bronder wrote:
> Due to a lack of time and the fact I don't use any of these packages 
> anymore, they are all up for grabs.

>
>  - media-gfx/openmesh [no project]
>  - sys-cluster/ganglia [cluster]
>  - sys-cluster/ganglia-web [cluster]
>  - sys-cluster/torque [cluster]
>  - sys-cluster/munge [cluster] dependency of sys-cluster/torque
>  - sys-cluster/mpe2 [cluster]
>
> Also, if there's anyone out there using the science overlay and empi 
> who's feeling motivated, that work still needs a champion to get it

> into the main tree.  If not, I'll probably drop it in a few months
> and open openmpi and mpich2 to project maintenance as well.  I
> haven't been involved in HPC for over a decade now, it's time to
> pass the torch.


Hello Justin,

I've been working on cluster ebuilds for a while (Apache Mesos, spark, 
etc). I'm willing to proxy maintain these except torque. Assuming there 
are no users of torque on gentoo (bgo seems inactive...it's dead; how 
would I know?).


My focus is building gentoo centric HPC clusters that do not require 
systemd as a component, with deployment emphasis on bare-metal and 
minimized gentoo systems where only the codes absolutely necessary to 
support the necessary frameworks are dynamically installed. Many of the 
'retro' tools in this cluster space, are quite useful for my work.


The guidexml page for empi is old, so where do I read up on it's 
projected usage (just not familiar with that empi project/package).


James

Re: [gentoo-dev] Packages up for grabs

[Ian Stakenvicius]

On 02/06/16 11:42 AM, james wrote:
> On 06/01/2016 06:20 PM, Justin Bronder wrote:
>> Due to a lack of time and the fact I don't use any of these packages
>> anymore, they are all up for grabs.
>>
>>  - media-gfx/openmesh [no project]
>>  - sys-cluster/ganglia [cluster]
>>  - sys-cluster/ganglia-web [cluster]
>>  - sys-cluster/torque [cluster]
>>  - sys-cluster/munge [cluster] dependency of sys-cluster/torque
>>  - sys-cluster/mpe2 [cluster]
>>
>> Also, if there's anyone out there using the science overlay and empi
>> who's feeling motivated, that work still needs a champion to get it
>> into the main tree.  If not, I'll probably drop it in a few months
>> and open openmpi and mpich2 to project maintenance as well.  I
>> haven't been involved in HPC for over a decade now, it's time to
>> pass the torch.
> 
> 
> Hello Justin,
> 
> I've been working on cluster ebuilds for a while (Apache Mesos, spark,
> etc). I'm willing to proxy maintain these except torque. Assuming
> there are no users of torque on gentoo (bgo seems inactive...it's
> dead; how would I know?).


I can step up and maintain or co-maintain sys-cluster/torque , I use
it at work and have contributed to it in the past.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Raymond Jennings]

use case:  Telling a package to build a gui without deciding which one to
build.  Also helps in cases where you have package A that can only build a
qt gui, and package B that can build both qt and gtk, and package C that
can build gtk only.  You want to have a gui for all three, but you don't
want to hav epackage B build both guis and at the same time while you may
prefer qt, you don't want to leave package C without a gui.

On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius  wrote:

> On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote:
> > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> >
> >> waltd...@waltdnes.org wrote:
> >>
> >>>   I see this as at least a redundancy, if not a problem.  First, let's
> >>> look at the general case.  An optional "UI" (User Interface) is also
> >>> selected...
> >>> * via the "tools" useflag 78 times in use.local.desc
> >>> * via the "ncurses" useflag 10 times in use.local.desc.
> >>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >>>   does "ncurses" show up in use.local.desc ???)
> >>>
> >>>  There is no need for an additional "TUI" (Text User Interface) use
> flag
> >>> for these cases.  "tools" and/or "ncurses" tells you enough.
> Similarly,
> >>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> >>> thing they have in common is a hard-coded dependancy on graphics libs.
> >>> "GUI" is an implicit dependancy of
> gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> >>> Using any of them tells you enough.  What do we accomplish by requiring
> >>> one more USE flag?  This will also make dependancy resolution of
> ebuilds
> >>> more complex, i.e. slower.  Why?
> >>
> >> Simple regular users don't want to be concerned with choice of toolkit
> >> for every single package, as long as a GUI is provided.
> >
> >   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> > make.conf.  This will *FORCE* a gui where applicable.
> >
>
>
> The whole point of USE=gui is to get away from needing to do that.
> Those flags should be used to choose -which- gui toolkit users want
> when one is available, not to choose IF a gui should be built or not.
> Take my example into account, i don't want anything qt based if I can
> avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
> not going to set that globally though because I don't want to choose
> qt4 based front-ends for anything else, and having to guess for every
> random package when i don't care so that I can set a package.use entry
> for it is annoying.
>
>
> >> Furthermore, this matches the recommended USE flag design where the
> >> more important flags are provided as feature flags, while specific
> >> dependency choice flags are minor.
> >
> >   This is going to require *THREE* levels of flags, with the first one
> > being totally unnecessary...
> >
> > Level 1) GUI
> >
> > Level 2) X or xorg or Wayland or Mir
> >
> > Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
>
>
> 1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
> needed.
>
> 2 - If X or Wayland or Mir support is available in a package, then yes
> -- also i don't see a way that we don't need these.
>
> 3 - toolkit selection choices when a package supports multiple (but
> only chooses one) is also a yes.  AND, because we're not tying any-gui
> to one of these flags it means that users are free to set just the one
> variant that they prefer, globally, instead of having to mess about
> per-package.  It also means we can get rid of any or all of these
> particular flags from profiles (except for 'gnome' or 'plasma' or the
> desktop-variant-specific ones).
>
> The point here is that if there's an app (say, wpa_supplicant as
> mentioned before) that provides a gui tool but no options as to what
> that tool needs in terms of toolkit etc, we can -just- have USE=gui
> control whether or not it's built.  It'll pull in qt because qt is
> what it needs, and if someone is dead set against having qt in their
> system then they'll know from the dependency tree.  There's no need to
> peg the individual toolkit to packages like this just to enable a gui.
>
>
> >
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> > or xorg or Wayland or Mir being a requirement for any of
> > qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> > a GUI of one sort or another.
>
>
> Likely there is but I'd need to search.  Extending libraries mostly --
> cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...
>
>
>
>
>

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 06:50:59AM +0100, Graham Murray wrote
> waltd...@waltdnes.org writes:
> 
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?
> 
> Yes. X/xorg could be needed to incorporate the X Client libraries so
> that X servers can connect to it but not itself have a gui. This
> could, for example, be on a headless server.

  Is it broken right now?  What improvement will we see from having to
add a "GUI" flag?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
> 
> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> users who don't want to care about X/wayland/mir and do not want to care 
> about gtk/qt, they just want windows to be drawn for the applications 
> they install -- without, if possible, pulling useless dependencies.

  How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[Damien Levac]

On 2016-06-02 03:42 PM, waltd...@waltdnes.org wrote:

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote

IMHO, you see this in reverse. the 'gui' useflag would be useful for
users who don't want to care about X/wayland/mir and do not want to care
about gtk/qt, they just want windows to be drawn for the applications
they install -- without, if possible, pulling useless dependencies.

   How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?
It will be linked to one of those, but the users don't want to care so 
reasonable default would apply.


For example, if I have setup my profile to be 'plasma', then having 
'gui' in my global use flags would mean "build with qt5 support to 
provide my gui whenever possible, if not possible, fallback to whatever 
is available at the discretion of the package maintainer".


2 nice properties I foresee this feature will have:

* If you do not like it, don't use it. It shouldn't affect any user 
unless they explicitly use the flag.
* Negating the flag would mean to not build any GUI (i.e. headless 
server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X 
-waylang...'


I do not think the question is whether the flag would be useful: it 
will. The question is: can it be implemented efficiently...

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:
> On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
>>
>> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
>> users who don't want to care about X/wayland/mir and do not want to care 
>> about gtk/qt, they just want windows to be drawn for the applications 
>> they install -- without, if possible, pulling useless dependencies.
> 
>   How, exactly, will the app draw windows without linking against one of
> X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> pike?
> 

The "useless dependencies" is the result of one or more of these
random flags being enabled globally when an end-user just wants to
make sure they get the GUI built for their apps.







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
> On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:
> > On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
> >>
> >> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> >> users who don't want to care about X/wayland/mir and do not want to care 
> >> about gtk/qt, they just want windows to be drawn for the applications 
> >> they install -- without, if possible, pulling useless dependencies.
> > 
> >   How, exactly, will the app draw windows without linking against one of
> > X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> > pike?
> > 
> 
> The "useless dependencies" is the result of one or more of these
> random flags being enabled globally when an end-user just wants to
> make sure they get the GUI built for their apps.

  The original discussion was about global defaults.  If you want
per-app settings, package.use is your friend.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{osdt,weblint}

[Patrice Clement]

# Patrice Clement  (2 Jun 2016)
# Ancient software (1996!). Unmaintained.
# Masked for removal in 30 days.
dev-util/weblint

# Patrice Clement  (2 Jun 2016)
# Dead upstream. No release since 2009.
# Masked for removal in 30 days.
dev-util/osdt

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Thu, 2 Jun 2016 16:37:58 -0400
waltd...@waltdnes.org wrote:

> On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
> > On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:  
> > > On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote  
> > >>
> > >> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> > >> users who don't want to care about X/wayland/mir and do not want to care 
> > >> about gtk/qt, they just want windows to be drawn for the applications 
> > >> they install -- without, if possible, pulling useless dependencies.  
> > > 
> > >   How, exactly, will the app draw windows without linking against one of
> > > X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> > > pike?
> > >   
> > 
> > The "useless dependencies" is the result of one or more of these
> > random flags being enabled globally when an end-user just wants to
> > make sure they get the GUI built for their apps.  
> 
>   The original discussion was about global defaults.  If you want
> per-app settings, package.use is your friend.

I'm going to keep this short: please try to understand that not
everyone can spend hours of time adjusting every single package
in Gentoo so that it may finally start working as expected.

We understand that some people have goals like 'I want Qt everywhere,
I hate GTK+ so much I'd rather not be able to do anything than have
GTK+ on my system'. We respect them. But we're no longer going to
optimize Gentoo for those people.

-- 
Best regards,
Michał Górny



pgpURU0KLB1wz.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Igor Savlook]

On 06/02/16 23:46, Michał Górny wrote:

On Thu, 2 Jun 2016 16:37:58 -0400
waltd...@waltdnes.org wrote:


On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote

On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote


IMHO, you see this in reverse. the 'gui' useflag would be useful for
users who don't want to care about X/wayland/mir and do not want to care
about gtk/qt, they just want windows to be drawn for the applications
they install -- without, if possible, pulling useless dependencies.


   How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?



The "useless dependencies" is the result of one or more of these
random flags being enabled globally when an end-user just wants to
make sure they get the GUI built for their apps.


   The original discussion was about global defaults.  If you want
per-app settings, package.use is your friend.


I'm going to keep this short: please try to understand that not
everyone can spend hours of time adjusting every single package
in Gentoo so that it may finally start working as expected.

We understand that some people have goals like 'I want Qt everywhere,
I hate GTK+ so much I'd rather not be able to do anything than have
GTK+ on my system'. We respect them. But we're no longer going to
optimize Gentoo for those people.


Ok if i want just disable gtk i use USE="-gtk -gtk2 -gtk3".

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Thu, Jun 2, 2016 at 4:46 PM, Michał Górny  wrote:
>
> We understand that some people have goals like 'I want Qt everywhere,
> I hate GTK+ so much I'd rather not be able to do anything than have
> GTK+ on my system'. We respect them. But we're no longer going to
> optimize Gentoo for those people.
>

++

I think this is the right direction to take.  Packages should try to
use the appropriate libraries by default (assuming they support more
than one), so the plasma user gets apps linked to qt5, and so on.  The
user shouldn't have to set USE flags to get basic behavior like this -
maybe they just pick a profile.

If a plasma user installs a package that only supports gtk, then it
pulls in gtk.

Users shouldn't need a laundry list of global or per-package USE
settings if they don't really care which libraries they need.  This
reasonable default behavior also shouldn't result in every single
package pulling in every possible optional dependency as well.  It
should just use the "right" one.

If somebody wants to set USE=-* and micromanage every package, well,
that will always work on Gentoo.  However, that should not be the use
case we optimize for.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/02/2016 12:57 PM, Damien Levac wrote:
> 
> 
> On 2016-06-02 03:42 PM, waltd...@waltdnes.org wrote:
>> On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
>>> IMHO, you see this in reverse. the 'gui' useflag would be useful for
>>> users who don't want to care about X/wayland/mir and do not want to care
>>> about gtk/qt, they just want windows to be drawn for the applications
>>> they install -- without, if possible, pulling useless dependencies.
>>How, exactly, will the app draw windows without linking against one of
>> X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
>> pike?
> It will be linked to one of those, but the users don't want to care so
> reasonable default would apply.
> 
> For example, if I have setup my profile to be 'plasma', then having
> 'gui' in my global use flags would mean "build with qt5 support to
> provide my gui whenever possible, if not possible, fallback to whatever
> is available at the discretion of the package maintainer".
> 
> 2 nice properties I foresee this feature will have:
> 
> * If you do not like it, don't use it. It shouldn't affect any user
> unless they explicitly use the flag.
> * Negating the flag would mean to not build any GUI (i.e. headless
> server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X
> -waylang...'
> 
> I do not think the question is whether the flag would be useful: it
> will. The question is: can it be implemented efficiently...
> 
> 
To play devil's advocate, can we get a citation on "users don't want to
care"? Which users? Does Gentoo have a lot of users who don't care, or
does it attract a more passionate audience that enjoys the control that
comes with being source-based? I'm inclined to believe the latter, but
I'm ready to be wrong.

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Thu, Jun 2, 2016 at 5:20 PM, Igor Savlook  wrote:
> Ok if i want just disable gtk i use USE="-gtk -gtk2 -gtk3".
>

And that is fine if your goal is to disable gtk.  Most people don't
have goals like this - their goal is probably to prefer qt, not to
disable gtk, and so on.  If you prefer a package with no gui to a
package with a gtk gui then what you proposed is the way to go about
it.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/02/2016 01:46 PM, Michał Górny wrote:
> On Thu, 2 Jun 2016 16:37:58 -0400
> waltd...@waltdnes.org wrote:
> 
>> On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
>>> On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:  
 On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote  
>
> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> users who don't want to care about X/wayland/mir and do not want to care 
> about gtk/qt, they just want windows to be drawn for the applications 
> they install -- without, if possible, pulling useless dependencies.  

   How, exactly, will the app draw windows without linking against one of
 X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
 pike?
   
>>>
>>> The "useless dependencies" is the result of one or more of these
>>> random flags being enabled globally when an end-user just wants to
>>> make sure they get the GUI built for their apps.  
>>
>>   The original discussion was about global defaults.  If you want
>> per-app settings, package.use is your friend.
> 
> I'm going to keep this short: please try to understand that not
> everyone can spend hours of time adjusting every single package
> in Gentoo so that it may finally start working as expected.
> 
> We understand that some people have goals like 'I want Qt everywhere,
> I hate GTK+ so much I'd rather not be able to do anything than have
> GTK+ on my system'. We respect them. But we're no longer going to
> optimize Gentoo for those people.
> 
Who are you speaking for with "we"?

The Gentoo GNOME team? Upstream GNOME? Some employer who's hiring
someone to introduce these flags to Gentoo? Outspoken users who have
(strangely) only spoken to a few developers with their concerns?

The council's not voted on this issue, so you're definitely not speaking
for all of us.

(Note I'm not necessarily against this USE flag deal, but we shouldn't
be speaking for anyone but ourselves here.)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell  wrote:
> To play devil's advocate, can we get a citation on "users don't want to
> care"? Which users? Does Gentoo have a lot of users who don't care, or
> does it attract a more passionate audience that enjoys the control that
> comes with being source-based? I'm inclined to believe the latter, but
> I'm ready to be wrong.
>

I'm willing to believe we have a lot of users who love micromanaging
USE flags.  The day Gentoo requires this sort of behavior to work
correctly is the day I won't be a user...  :)

Gentoo SHOULD give users choices.  It should also pick reasonable
defaults when users opt not to specify a choice.

Obviously if a user just wants Ubuntu or Arch they should just install
Ubuntu or Arch.  However, I think a common use case is going to be a
user wants very fine-grained control over a particular aspect of their
system, but they're not going to care about the rest.  Maybe a user
does a lot of development in a particular language and they want
fine-grained control over how their compiler/interpreter/etc works,
but that doesn't mean that when they fire up a browser to check
stackexchange that they want to tweak every setting.  Maybe somebody
has a server used for media transcoding and they want to tweak all the
ffmpeg/libav build options, but otherwise want a distro that just
works as far as ssh/openrc/systemd and so on goes.

It would be one thing if we had to sacrifice the super-OCD users to
cater to the non-OCD users.  However, I don't really see a reason why
we can't service both.  This proposal works for either set of users.
If a package doesn't give fine-grained control over libraries then the
OCD users aren't really losing anything they had before.  If it does
then USE=+gui gets the users who don't care their gui, and it still
lets the people who want to tweak qt/gtk/etc the ability to do so.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/02/2016 02:55 PM, Rich Freeman wrote:
> On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell  wrote:
>> To play devil's advocate, can we get a citation on "users don't want to
>> care"? Which users? Does Gentoo have a lot of users who don't care, or
>> does it attract a more passionate audience that enjoys the control that
>> comes with being source-based? I'm inclined to believe the latter, but
>> I'm ready to be wrong.
>>
> 
> I'm willing to believe we have a lot of users who love micromanaging
> USE flags.  The day Gentoo requires this sort of behavior to work
> correctly is the day I won't be a user...  :)
> 
> Gentoo SHOULD give users choices.  It should also pick reasonable
> defaults when users opt not to specify a choice.
I agree. Sane defaults are what make system maintenance easy.

> 
> Obviously if a user just wants Ubuntu or Arch they should just install
> Ubuntu or Arch.  However, I think a common use case is going to be a
> user wants very fine-grained control over a particular aspect of their
> system, but they're not going to care about the rest.  Maybe a user
> does a lot of development in a particular language and they want
> fine-grained control over how their compiler/interpreter/etc works,
> but that doesn't mean that when they fire up a browser to check
> stackexchange that they want to tweak every setting.  Maybe somebody
> has a server used for media transcoding and they want to tweak all the
> ffmpeg/libav build options, but otherwise want a distro that just
> works as far as ssh/openrc/systemd and so on goes.
> 
> It would be one thing if we had to sacrifice the super-OCD users to
> cater to the non-OCD users.  However, I don't really see a reason why
> we can't service both.  This proposal works for either set of users.
> If a package doesn't give fine-grained control over libraries then the
> OCD users aren't really losing anything they had before.  If it does
> then USE=+gui gets the users who don't care their gui, and it still
> lets the people who want to tweak qt/gtk/etc the ability to do so.
> 
Well, that's the incoming problem when we accept USE="gui". I'm in favor
of the change in spirit, because who doesn't want a Gentoo that needs
less babysitting? However, the devil is in the details with what this
change leads to. Let's say we push the gui flag anyway. It is a good
idea, after all. Now how do we, as developers, deal with the
intricacies? There's adding +foo to IUSE, there's REQUIRED_USE, the
proposed USE_EXPAND (and a strange syntax added to clarify preference),
and pkg_pretend. All of these are possible solutions but *which*
solution most definitely will affect the "super-OCD" users. Ideally, we
should only need to tell these users where the new change goes, e.g.
"Don't set it in make.conf anymore, use p.use or p.env" or some other
thing. We need to make sure that there's only _one_ step needed for each
group. The "everyman" user can add USE="gui" and be done with it. The
picky user will need to set their preference in some other way, but it
should only be in one place instead of, say, two or three.

Let's use a concrete example here: x11-misc/spacefm. For another,
different example, net-p2p/transmission. The former supports two
versions of GTK, the latter accepts three (or more?) different toolkits,
in addition to ncurses which _might_ be considered a GUI to some. (It
seems that GTK2 support is no longer accepted; is that upstream decision
or maintainer's? But I digress...)

Currently, setting that preference ("Screw qt4 I want qt5" or "Screw
GTK3 I want 2!") usually requires either a global make.conf setup (which
some of us are against due to it meaning different things in different
packages), or adding a p.use entry for every piece of software that one
has an opinion on. Sometimes REQUIRED_USE necessitates negating the
other options. (I regret that spacefm does this, but I'm not changing it
until we have a real solution)

If the USE_EXPAND is used, we get the GUI variable in make.conf that can
then be used to hint ebuilds as to what the user finds acceptable. If
they love Qt5 on everything except that one program, then -gui_qt5 in
p.use for that one program would work, and make sense. Choice of toolkit
is usually a global decision, so the GUI USE sounds great, until we get
conflicts. We then have to figure out what the preferred way to resolve
that conflict. For example, let's say someone adds gtk2 and qt5 to their
GUI in make.conf. A particular ebuild supports both. Do we hack the
build system to make two versions of the program? Do we perform the same
option that they'd get if it was just USE="gui"? What will our DEPENDS
look like after enacting this change? We need an honest answer about
this, even if it's just "maintainer discretion" and/or "use pkg_pretend".

In short, I'm in support of this _idea_, but until we have some sort of
suggestion on how maintainers should implement this for their users,
we're going to get inconsistency between maintainers and the 

Re: [gentoo-dev] [RFC] Global USE=gui

[Nick Vinson]

On 06/02/2016 08:08 AM, Raymond Jennings wrote:
> use case:  Telling a package to build a gui without deciding which one
> to build.  Also helps in cases where you have package A that can only
> build a qt gui, and package B that can build both qt and gtk, and
> package C that can build gtk only.  You want to have a gui for all
> three, but you don't want to hav epackage B build both guis and at the
> same time while you may prefer qt, you don't want to leave package C
> without a gui.

How do you decide which one package B builds in such a case?

Honestly, I don't think this is a good idea.  The rationale  and
suggested implementation just don't bring enough benefit in my opinion.
Often times it's hard enough to research a reported issue with the
current implementation.  Having a flag like 'gui' whose behavior
(potentially) changes based on what profile is being used makes things
considerably harder.  It would no longer be a simple matter of matching
versions and USE flags, the package maintainer would also need to setup
an equivalent system with the same profile or research what the 'gui'
flag with profile 'x' does and setup an equivalent USE flag set.

Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
do the same thing.  The only thing they don't do (as I understand the
profiles) is enable GUI support for packages that don't support the
preferred libraries.  Is that really enough justification to implement
this flag?

As a maintainer I'd ask that, at the very least, a more compelling
reason than "it's too annoying to update package.use" is given.  I find
the argument against putting all the flags in global a valid but weak as
there are already mitigations for that scenario.   Perhaps I'm missing
something, but I'm not convinced this will provide a significant enough
benefit to the average Gentoo user to offset the increased
troubleshooting demand it'll put on Gentoo's developers, maintainers,
and proxy-maintainers.

Thanks,
Nicholas Vinson

P.S. I'd also like to add that I do spend a considerable amount of time
in #gentoo and I don't recall seeing this problem come up that much.
The closest I've seen was a user asking where /usr/bin/VirtualBox was
(as it only gets installed when the proper qt USE flag is set), but
based on personal experience that happens maybe 1 or 2 every 3 - 4
months (if that often).

> 
> On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius  > wrote:
> 
> On 01/06/16 10:13 PM, waltd...@waltdnes.org
>  wrote:
> > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> >
> >> waltd...@waltdnes.org  wrote:
> >>
> >>>   I see this as at least a redundancy, if not a problem.  First, let's
> >>> look at the general case.  An optional "UI" (User Interface) is also
> >>> selected...
> >>> * via the "tools" useflag 78 times in use.local.desc
> >>> * via the "ncurses" useflag 10 times in use.local.desc.
> >>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >>>   does "ncurses" show up in use.local.desc ???)
> >>>
> >>>  There is no need for an additional "TUI" (Text User Interface) use 
> flag
> >>> for these cases.  "tools" and/or "ncurses" tells you enough.  
> Similarly,
> >>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> >>> thing they have in common is a hard-coded dependancy on graphics libs.
> >>> "GUI" is an implicit dependancy of 
> gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> >>> Using any of them tells you enough.  What do we accomplish by 
> requiring
> >>> one more USE flag?  This will also make dependancy resolution of 
> ebuilds
> >>> more complex, i.e. slower.  Why?
> >>
> >> Simple regular users don't want to be concerned with choice of toolkit
> >> for every single package, as long as a GUI is provided.
> >
> >   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> > make.conf.  This will *FORCE* a gui where applicable.
> >
> 
> 
> The whole point of USE=gui is to get away from needing to do that.
> Those flags should be used to choose -which- gui toolkit users want
> when one is available, not to choose IF a gui should be built or not.
> Take my example into account, i don't want anything qt based if I can
> avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
> not going to set that globally though because I don't want to choose
> qt4 based front-ends for anything else, and having to guess for every
> random package when i don't care so that I can set a package.use entry
> for it is annoying.
> 
> 
> >> Furthermore, this matches the recommended USE flag design where the
> >> more important flags are provided as feature flags, while specific
> >> depend