[gentoo-dev] RFC: new "qt" category

[gentoo-dev] RFC: new "qt" category

[Ben de Groot]

Hi guys,

Presently we already have a good number of split qt-* library packages
in x11-libs. With the arrival of Qt5 upstream has gone a lot further
in modularization, so we expect the number of packages to grow much
more. We, the Gentoo Qt team, are of the opinion that the time has
come to split all these out into their own category. This category is
to be used for the various modules and applications that belong to the
upstream Qt Framework only (these include e.g. assistant and
linguist). Third-party applications should remain in the current
categories.

After some initial bikeshedding we came to the conclusion that naming
the category simply "qt" is the most elegant solution. We will then
also be dropping the qt- prefix in package names. This means
x11-libs/qt-core will be moved to qt/core, and so on.

Please let us know your thought on this.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Ian Whyman]

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

Much nicer naming IMHO.

+1 from me.

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

Re: [gentoo-dev] RFC: new "qt" category

[Diego Elio Pettenò]

On 17/01/2013 14:57, Ben de Groot wrote:
> After some initial bikeshedding we came to the conclusion that naming
> the category simply "qt" is the most elegant solution. We will then
> also be dropping the qt- prefix in package names. This means
> x11-libs/qt-core will be moved to qt/core, and so on.

Please don't. Right now we have only one category which is not foo-bar
and that's virtual... I'm pretty sure it's going to break some
assumption to change that...

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] RFC: new "qt" category

[Chí-Thanh Christopher Nguyễn]

Ben de Groot schrieb:
> This category is
> to be used for the various modules and applications that belong to the
> upstream Qt Framework only (these include e.g. assistant and
> linguist). Third-party applications should remain in the current
> categories.

So where do modules go that come from upstream but are not part of Qt
itself, if such packages exist or are going to exist? Did you entertain
the idea of having qt-base (for qt-core, qt-gui, ...) and qt-extra (for
qca, qwt, ...) categories? This would also address Diego's comment.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: new "qt" category

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -1 here.

It's a too specific category name. I can appreciate it easing the
headaches for the maintainers, but from a design POV I dislike it.
(For the record I also dislike KDE/GNOME/XFCE-categories.)

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlD4BooACgkQRtClrXBQc7VDDwD+OzMfRx1XA64AtbxYBUy2F1im
Llh9036grStFNAfLExMA/28ChZ5TXoPLIw1V1Pui7ZwNwPgFR6YaEEEw7w/8iI2O
=t4P9
-----END PGP SIGNATURE-----

[gentoo-dev] Re: RFC: new "qt" category

[Michael Palimaka]

On 18/01/2013 01:11, Alexander Berntsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> - -1 here.
>
> It's a too specific category name. I can appreciate it easing the
> headaches for the maintainers, but from a design POV I dislike it.
> (For the record I also dislike KDE/GNOME/XFCE-categories.)
Where would you place the 300ish KDE core packages then?

Re: [gentoo-dev] RFC: new "qt" category

[vivo75]

Il 17/01/2013 14:57, Ben de Groot ha scritto:
> Hi guys,
>
> Presently we already have a good number of split qt-* library packages
> in x11-libs. With the arrival of Qt5 upstream has gone a lot further
> in modularization, so we expect the number of packages to grow much
> more. We, the Gentoo Qt team, are of the opinion that the time has
> come to split all these out into their own category. This category is
> to be used for the various modules and applications that belong to the
> upstream Qt Framework only (these include e.g. assistant and
> linguist). Third-party applications should remain in the current
> categories.
>
> After some initial bikeshedding we came to the conclusion that naming
> the category simply "qt" is the most elegant solution.
+1 but use a '-' in the category qt-dev or qt-libs

>   We will then
> also be dropping the qt- prefix in package names. This means
> x11-libs/qt-core will be moved to qt/core, and so on.
-1
Because it would be nice to move there also qwt* and possibly other libs.
qt-libs/qt-core make it easyer to separate them
>
> Please let us know your thought on this.
thanks for asking

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 17 January 2013 22:05, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> On 17/01/2013 14:57, Ben de Groot wrote:
>> After some initial bikeshedding we came to the conclusion that naming
>> the category simply "qt" is the most elegant solution. We will then
>> also be dropping the qt- prefix in package names. This means
>> x11-libs/qt-core will be moved to qt/core, and so on.
>
> Please don't. Right now we have only one category which is not foo-bar
> and that's virtual... I'm pretty sure it's going to break some
> assumption to change that...

But is there any reason other than "assumption" to stick to foo-bar
category names?

One alternative we did come up with is qt-framework, since that is
what upstream also uses (though mostly it's plain Qt), since it's a
collection of libraries and applications.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 17 January 2013 22:09, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Ben de Groot schrieb:
>> This category is
>> to be used for the various modules and applications that belong to the
>> upstream Qt Framework only (these include e.g. assistant and
>> linguist). Third-party applications should remain in the current
>> categories.
>
> So where do modules go that come from upstream but are not part of Qt
> itself, if such packages exist or are going to exist? Did you entertain
> the idea of having qt-base (for qt-core, qt-gui, ...) and qt-extra (for
> qca, qwt, ...) categories? This would also address Diego's comment.

If they are not part of the Qt Framework as upstream defines it, then
they go into the respective categories, e.g. dev-util/qt-creator which
already exists.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Re: RFC: new "qt" category

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 15:25, Michael Palimaka wrote:
> Where would you place the 300ish KDE core packages then?
In whatever generic category they belong. I understand that the
monolithic nature makes it difficult from a maintainer POV, but from a
design POV it is more desirable for me.

To not stray from the topic, I am saying that I want to avoid a qt
category if possible. I'm not proposing a discussion about whether
KDE-* should exist or not. That's a different topic.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlD4Df4ACgkQRtClrXBQc7V3uQD9FYTxW8hSjfdY1vq2tbS4TQor
b6tNjL03FMN9LF8F7kUA/0G29lSdUngN77KGeCyt3W80NZdmGT736e9HhNhb5/u/
=UrKI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new "qt" category

[Samuli Suominen]

On 17/01/13 15:57, Ben de Groot wrote:
> Please let us know your thought on this.

+1

Re: [gentoo-dev] RFC: new "qt" category

[Diego Elio Pettenò]

On 17/01/2013 15:33, Ben de Groot wrote:
> But is there any reason other than "assumption" to stick to foo-bar
> category names?

Well I for one have used this before when I wanted to get informative
build logs: virtual/ packages have no build logs whatsoever so I don't
care to grep for them. It might be incidental but I don't see a
compelling reason to break free of it.

> One alternative we did come up with is qt-framework, since that is
> what upstream also uses (though mostly it's plain Qt), since it's a
> collection of libraries and applications.

How many packages are we talking about? Especially if you don't want qwt
to join there, I assume we're way below 50? If so I would vote nay to
any new category at all, to be honest.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] RFC: new "qt" category

[Ulrich Mueller]

>>>>> On Thu, 17 Jan 2013, Ben de Groot wrote:

> Presently we already have a good number of split qt-* library
> packages in x11-libs. With the arrival of Qt5 upstream has gone a
> lot further in modularization, so we expect the number of packages
> to grow much more. We, the Gentoo Qt team, are of the opinion that
> the time has come to split all these out into their own category.
> This category is to be used for the various modules and applications
> that belong to the upstream Qt Framework only (these include e.g.
> assistant and linguist). Third-party applications should remain in
> the current categories.

> After some initial bikeshedding we came to the conclusion that
> naming the category simply "qt" is the most elegant solution. We
> will then also be dropping the qt- prefix in package names. This
> means x11-libs/qt-core will be moved to qt/core, and so on.

> Please let us know your thought on this.

-1

Please don't invent a new naming scheme. All existing categories
follow a major-minor naming (except for virtual, and that one has
historical reasons).

Apart from this, I also don't think that naming it qt-* would be
justified. Why can't things stay in x11-libs, together with other
toolkits?

Ulrich

Re: [gentoo-dev] RFC: new "qt" category

[Ciaran McCreesh]

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

On Thu, 17 Jan 2013 15:05:53 +0100
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> On 17/01/2013 14:57, Ben de Groot wrote:
> > After some initial bikeshedding we came to the conclusion that
> > naming the category simply "qt" is the most elegant solution. We
> > will then also be dropping the qt- prefix in package names. This
> > means x11-libs/qt-core will be moved to qt/core, and so on.
> 
> Please don't. Right now we have only one category which is not foo-bar
> and that's virtual... I'm pretty sure it's going to break some
> assumption to change that...

Which is a good thing, since it will force people to stop making
incorrect assumptions.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: new "qt" category

[James Cloos]

>>>>> "BdG" == Ben de Groot <yngwin@gentoo.org> writes:

BdG> After some initial bikeshedding we came to the conclusion that naming
BdG> the category simply "qt" is the most elegant solution. We will then
BdG> also be dropping the qt- prefix in package names. This means
BdG> x11-libs/qt-core will be moved to qt/core, and so on.

Please don't.

Every current category matches /^[a-z]+-[a-z]+$/.  With the possible
exception of adding moving from [a-z]+ to [a-z0-9]+, that shoud remain.

Only non-category directories under /usr/portage should lack a hyphen.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] RFC: new "qt" category

[James Cloos]

>>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:

CM> Which is a good thing, since it will force people to stop making
CM> incorrect assumptions.

No, its a bad thing because it makes it harder to grep out the non
category dirs.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] RFC: new "qt" category

[Ciaran McCreesh]

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

On Thu, 17 Jan 2013 12:05:03 -0500
James Cloos <cloos@jhcloos.com> wrote:
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
> CM> Which is a good thing, since it will force people to stop making
> CM> incorrect assumptions.
> 
> No, its a bad thing because it makes it harder to grep out the non
> category dirs.

That's what's known as "doing it wrong". You should be querying your
package mangler for a list of categories, not doing an 'ls'.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: new "qt" category

[Ciaran McCreesh]

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

On Thu, 17 Jan 2013 12:03:36 -0500
James Cloos <cloos@jhcloos.com> wrote:
> Every current category matches /^[a-z]+-[a-z]+$/.  With the possible
> exception of adding moving from [a-z]+ to [a-z0-9]+, that shoud
> remain.

Untrue. 'virtual' doesn't. If you want the rules for what constitutes a
valid category name, consult PMS. If you want to know what categories
are actually present, consult 'profiles/categories' or your package
mangler.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: new "qt" category

[Rich Freeman]

On Thu, Jan 17, 2013 at 12:14 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 17 Jan 2013 12:03:36 -0500
> James Cloos <cloos@jhcloos.com> wrote:
>> Every current category matches /^[a-z]+-[a-z]+$/.  With the possible
>> exception of adding moving from [a-z]+ to [a-z0-9]+, that shoud
>> remain.
>
> Untrue. 'virtual' doesn't. If you want the rules for what constitutes a
> valid category name, consult PMS. If you want to know what categories
> are actually present, consult 'profiles/categories' or your package
> mangler.

Tend to agree.  We should use whatever makes the most sense.  I'm not
sure how many packages we're actually talking about though - might
make sense to introduce a new category when we need it.

There are a lot of assumptions people make which aren't backed by PMS.
 Probably the more common one is the concept that EAPIs are numerical
and/or orderable.  The whole concept of the "best/newest" EAPI depends
on that assumption.

Rich

Re: [gentoo-dev] RFC: new "qt" category

[Chris Reffett]

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

On 01/17/2013 08:57 AM, Ben de Groot wrote:
> Hi guys,
> 
> Presently we already have a good number of split qt-* library
> packages in x11-libs. With the arrival of Qt5 upstream has gone a
> lot further in modularization, so we expect the number of packages
> to grow much more. We, the Gentoo Qt team, are of the opinion that
> the time has come to split all these out into their own category.
> This category is to be used for the various modules and
> applications that belong to the upstream Qt Framework only (these
> include e.g. assistant and linguist). Third-party applications
> should remain in the current categories.
> 
> After some initial bikeshedding we came to the conclusion that
> naming the category simply "qt" is the most elegant solution. We
> will then also be dropping the qt- prefix in package names. This
> means x11-libs/qt-core will be moved to qt/core, and so on.
> 
> Please let us know your thought on this.
> 
+1ish. I'm all for a new category (specific naming scheme to be
bikeshedded, no preference there), but I think dropping the qt- prefix
will lead to overly generic/already existing package names: "gui"
"declarative" "dbus" "core" "opengl" etc. I don't see any value from
dropping the prefix that would justify this.
Chris Reffett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlD4RbIACgkQ23laikJhg1SUngCfatp7/zOP4iGym3sitfH6xpA6
mPAAn2+4HWyOF5+qj2DNIn9IjflOXYc4
=TuOb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new "qt" category

[James Cloos]

>>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:

CM> That's what's known as "doing it wrong". You should be querying your
CM> package mangler for a list of categories, not doing an 'ls'.

ls(1) isn't relevant.  find(1) is.  grep(1) is.  There are others.

Using the 'package managers' isn't very helpful.  They generally do
everything poorly.  And usually **s*l*o*w*l*y**, if they compile at
all.

I can't even remember every time I've needed to use a regex, glob or
other pattern match where the fact that the real categories had a dash
made things easier and faster.

Its been way too many years to change that now.

Much better to standardize it as m/[a-z0-9]+-[a-z0-9]+/.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] RFC: new "qt" category

[Ciaran McCreesh]

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

On Thu, 17 Jan 2013 14:35:12 -0500
James Cloos <cloos@jhcloos.com> wrote:
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
> CM> That's what's known as "doing it wrong". You should be querying
> CM> your package mangler for a list of categories, not doing an 'ls'.
> 
> ls(1) isn't relevant.  find(1) is.  grep(1) is.  There are others.
> 
> Using the 'package managers' isn't very helpful.  They generally do
> everything poorly.  And usually **s*l*o*w*l*y**, if they compile at
> all.

On the other hand, they do things correctly, which your approach
doesn't.

> I can't even remember every time I've needed to use a regex, glob or
> other pattern match where the fact that the real categories had a dash
> made things easier and faster.

But wrong. If you want wrong answers quickly, cat /dev/urandom.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: new "qt" category

[Georg Rudoy]

2013/1/17 Chris Reffett <creffett@gentoo.org>:
> but I think dropping the qt- prefix
> will lead to overly generic/already existing package names: "gui"
> "declarative" "dbus" "core" "opengl" etc. I don't see any value from
> dropping the prefix that would justify this.

+1.

--
  Georg Rudoy
  LeechCraft — http://leechcraft.org

Re: [gentoo-dev] RFC: new "qt" category

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 840 bytes --]

Am Donnerstag, 17. Januar 2013, 14:57:16 schrieb Ben de Groot:
> 
> After some initial bikeshedding we came to the conclusion that naming
> the category simply "qt" is the most elegant solution. We will then
> also be dropping the qt- prefix in package names. This means
> x11-libs/qt-core will be moved to qt/core, and so on.
> 

Please don't. 

This is not about standards, but about consistency. About everyone else uses 
the two-part category-names witha-dash. Why can't you? It is what I would 
immediately expect, instead of a "hyper-toplevel" "qt". 

My suggestion would be qt-base (analogous to kde-base, gnome-base, gnustep-
base, lxde-base, and xfce-base) for everything that is part of the main Qt 
release.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-dev] RFC: new "qt" category

[Alec Warner]

On Thu, Jan 17, 2013 at 2:46 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Am Donnerstag, 17. Januar 2013, 14:57:16 schrieb Ben de Groot:
>>
>> After some initial bikeshedding we came to the conclusion that naming
>> the category simply "qt" is the most elegant solution. We will then
>> also be dropping the qt- prefix in package names. This means
>> x11-libs/qt-core will be moved to qt/core, and so on.
>>
>
> Please don't.
>
> This is not about standards, but about consistency. About everyone else uses
> the two-part category-names witha-dash. Why can't you? It is what I would
> immediately expect, instead of a "hyper-toplevel" "qt".
>
> My suggestion would be qt-base (analogous to kde-base, gnome-base, gnustep-
> base, lxde-base, and xfce-base) for everything that is part of the main Qt
> release.

I'd actually argue that qt/core qt/base and other such 'package names'
are in fact a better reason why this is a terrible idea. Remember that
in some places (like emerge) the category is optional.

emerge core base => not obvious

-A

>
> --
>
> Andreas K. Huettel
> Gentoo Linux developer
> dilfridge@gentoo.org
> http://www.akhuettel.de/
>

Re: [gentoo-dev] RFC: new "qt" category

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1233 bytes --]

On Thursday 17 January 2013 14:44:14 Ciaran McCreesh wrote:
> On Thu, 17 Jan 2013 14:35:12 -0500 James Cloos wrote:
> > >>>>> "CM" == Ciaran McCreesh writes:
> > CM> That's what's known as "doing it wrong". You should be querying
> > CM> your package mangler for a list of categories, not doing an 'ls'.
> > 
> > ls(1) isn't relevant.  find(1) is.  grep(1) is.  There are others.
> > 
> > Using the 'package managers' isn't very helpful.  They generally do
> > everything poorly.  And usually **s*l*o*w*l*y**, if they compile at
> > all.
> 
> On the other hand, they do things correctly, which your approach
> doesn't.
> 
> > I can't even remember every time I've needed to use a regex, glob or
> > other pattern match where the fact that the real categories had a dash
> > made things easier and faster.
> 
> But wrong. If you want wrong answers quickly, cat /dev/urandom.

and breaking people for no good reason is just that -- not a good reason.

is code that makes this assumption kind of crappy ?  yes.  is this new 
proposal a compelling use case for breaking that (pretty common) assumption ?  
no.  there's no real technical overhead to have new qt categories follow the 
existing practice.
-mike

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

Re: [gentoo-dev] RFC: new "qt" category

[Markos Chandras]

On 18 January 2013 04:24, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 17 January 2013 14:44:14 Ciaran McCreesh wrote:
>> On Thu, 17 Jan 2013 14:35:12 -0500 James Cloos wrote:
>> > >>>>> "CM" == Ciaran McCreesh writes:
>> > CM> That's what's known as "doing it wrong". You should be querying
>> > CM> your package mangler for a list of categories, not doing an 'ls'.
>> >
>> > ls(1) isn't relevant.  find(1) is.  grep(1) is.  There are others.
>> >
>> > Using the 'package managers' isn't very helpful.  They generally do
>> > everything poorly.  And usually **s*l*o*w*l*y**, if they compile at
>> > all.
>>
>> On the other hand, they do things correctly, which your approach
>> doesn't.
>>
>> > I can't even remember every time I've needed to use a regex, glob or
>> > other pattern match where the fact that the real categories had a dash
>> > made things easier and faster.
>>
>> But wrong. If you want wrong answers quickly, cat /dev/urandom.
>
> and breaking people for no good reason is just that -- not a good reason.
>
> is code that makes this assumption kind of crappy ?  yes.  is this new
> proposal a compelling use case for breaking that (pretty common) assumption ?
> no.  there's no real technical overhead to have new qt categories follow the
> existing practice.
> -mike

I also like the current style for categories (foo-bar) and I also like
the "qt-framework" or "qt-libs" proposals but now that I think about
it again, I see no urgent reason to move away from x11-libs. I also
dislike the idea to drop the qt-* prefix from the Qt modules.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] RFC: new "qt" category

[Federico "fox" Scrinzi]

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

On 17/01/2013 14:57, Ben de Groot wrote:
> Presently we already have a good number of split qt-* library packages
> in x11-libs.

How many?

└> ls -d /usr/portage/x11-libs/qt* | wc -l
22

> We, the Gentoo Qt team, are of the opinion that the time has
> come to split all these out into their own category.

-1
No way.

> This means x11-libs/qt-core will be moved to qt/core, and so on.

Do you really want me to do "emerge core"?

Moreover all other categories are called "major-minor" as Diego pointed
out. Consistency matters.

-- 
f.

  "There are only two hard things in Computer Science: cache
   invalidation, naming things and off-by-one errors."


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

Re: [gentoo-dev] RFC: new "qt" category

[Christoph Junghans]

2013/1/17 Ben de Groot <yngwin@gentoo.org>:
> Hi guys,
>
> Presently we already have a good number of split qt-* library packages
> in x11-libs. With the arrival of Qt5 upstream has gone a lot further
> in modularization, so we expect the number of packages to grow much
> more. We, the Gentoo Qt team, are of the opinion that the time has
> come to split all these out into their own category. This category is
> to be used for the various modules and applications that belong to the
> upstream Qt Framework only (these include e.g. assistant and
> linguist). Third-party applications should remain in the current
> categories.
>
> After some initial bikeshedding we came to the conclusion that naming
> the category simply "qt" is the most elegant solution. We will then
> also be dropping the qt- prefix in package names. This means
> x11-libs/qt-core will be moved to qt/core, and so on.
-1

I don't like the idea of emerging gui instead qt-qui.
>
> Please let us know your thought on this.
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>



--
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 19 January 2013 03:22, Christoph Junghans <ottxor@gentoo.org> wrote:
> 2013/1/17 Ben de Groot <yngwin@gentoo.org>:
>> After some initial bikeshedding we came to the conclusion that naming
>> the category simply "qt" is the most elegant solution. We will then
>> also be dropping the qt- prefix in package names. This means
>> x11-libs/qt-core will be moved to qt/core, and so on.
> -1
>
> I don't like the idea of emerging gui instead qt-qui.

The thing is you would practically never have to do this. Users
install apps that have a number of qt modules as dependencies. These
qt modules in turn cannot be updated individually (unless there is an
ebuild revision bump), but will be included in a world update as a
group.

And if you really must, is emerge qt/gui so much more difficult than
emerge qt-gui?

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 17 January 2013 22:45, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> How many packages are we talking about? Especially if you don't want qwt
> to join there, I assume we're way below 50? If so I would vote nay to
> any new category at all, to be honest.

Roughly 40 is the current estimate. This is above the median 32 per
category in the current tree, if that means anything.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Diego Elio Pettenò]

On Sat, Jan 19, 2013 at 11:56 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> The thing is you would practically never have to do this. Users
> install apps that have a number of qt modules as dependencies. These
> qt modules in turn cannot be updated individually (unless there is an
> ebuild revision bump), but will be included in a world update as a
> group.

Beside the fact that yes, it happens sometimes that you want to
rebuild only one of them, and doing 'emerge gui' is nasty enough, what
about dbus?

emerge dbus -> which one did you mean now? Yes there's a category, but
that's not a good reason to artificially make it more complicated.

I'm pretty sure that if a consensus is to be found, it is that 'qt' as
a category name, and dropping the 'qt-' prefix, is not seen with
favour by other people beside you and whoever you discussed this with.
I would thus ask you to drop that idea.

Some of us, including me, are also wondering why a separate category
is needed — while you might be over the median, it doesn't mean it's
that much more compelling — indeed my feeling is that it would be an
useless small category, especially if you only want to keep the core
and it won't ever grow. But I won't stop you if it's going to be
qt-core/qt-core as package name.

Re: [gentoo-dev] RFC: new "qt" category

[Rich Freeman]

On Sat, Jan 19, 2013 at 7:43 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> Some of us, including me, are also wondering why a separate category
> is needed — while you might be over the median, it doesn't mean it's
> that much more compelling — indeed my feeling is that it would be an
> useless small category, especially if you only want to keep the core
> and it won't ever grow. But I won't stop you if it's going to be
> qt-core/qt-core as package name.

I tend to agree on leaving qt in the package names themselves for the
reasons that have been raised.

I'm not sure that the category "qt-core" makes sense though.

Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen
for its own sake and we're just making senseless stuff up.  qt-core
just doesn't make sense if it applies to more than just qt-core.

If the reason for the hyphen is to have some kind of major/minor
category organization then it really makes sense to not create a new
major category just for qt since we'll only have one category for it.
x11-qt or dev-qt are probably the best fits with what is there now.
If we want to create a new major category then maybe some kind of
general category for large development toolkits would make sense, but
I just don't see the demand.

I do support the idea of a new category for qt though, if they really
are going to have upwards of 40 packages.  That would put x11-libs up
to 180 packages, and qt would be 20% of them.

Rich

Re: [gentoo-dev] RFC: new "qt" category

[Diego Elio Pettenò]

On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen
> for its own sake and we're just making senseless stuff up.  qt-core
> just doesn't make sense if it applies to more than just qt-core.

I actually love x11-qt as an option.

Re: [gentoo-dev] RFC: new "qt" category

[Patrick Lauer]

On 01/19/2013 09:39 PM, Diego Elio Pettenò wrote:
> On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen
>> for its own sake and we're just making senseless stuff up.  qt-core
>> just doesn't make sense if it applies to more than just qt-core.
> 
> I actually love x11-qt as an option.
> 
That's silly, the x11 bit (qt-gui) is just one of the modules. You can
have everything else installed without needing x11 at all ...

Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?

Re: [gentoo-dev] RFC: new "qt" category

[Rich Freeman]

On Sat, Jan 19, 2013 at 8:46 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?

I was thinking about that.  A lib-misc, lib-x11, lib-qt, and so on
organization actually makes more sense to me than what we're doing
with libs in general right now.  But, that is a bigger change.

Unless we plan to have more categories under lib-* I'm not sure it
makes sense to do that for qt alone.

Rich

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 19 January 2013 21:46, Patrick Lauer <patrick@gentoo.org> wrote:
> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?

These are libraries and applications that are used by developers of
end-user applications.

If there is too much opposition to a simple "qt" category (at least
there seems to be some quite vocal opposition), then dev-qt is in my
eyes the next best alternative. A third option we came up with is
qt-framework.

Somewhat comparable categories in the current tree are dev-dotnet and
gnustep-{base,libs}.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Michael Weber]

On 01/19/2013 03:14 PM, Ben de Groot wrote:
> On 19 January 2013 21:46, Patrick Lauer <patrick@gentoo.org> wrote:
>> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?
> 
> These are libraries and applications that are used by developers of
> end-user applications.
And so is vim, which is used as editor, by devs.

My initial reading of the posted line "categories are foo[-]bar"
reminded me of some discussion with archlinux enthusiasts which find
them stupid.

It all boils down to: Do we want categories or not?

Categories are nasty, I always fail on `emerge -av1 screen` which
resolves to app-misc/screen and app-vim/screen.

Besides the limitation, categorization creates structure,
Does it belong to gnome or kde? is it an x11 app? is it an application
or just an library? and so on ..

We have a fixed number of exact 2 tags (foo and bar),
This limitation has proven it's usability in the past of Gentoo, but
there are reasons to break it up (Like making up funny points like regex
and it has always been this way). foo-bar-baz might be usefull, too.

But it's plain redundacy to in insist on *qt*/qt-*.

Either reject using an appropriate category and place it
as misc-randoom/qt-* or use a category and strip the "qt-" prefix.

I'm fine with qt/core, my preference would be lib-qt/core or lib/qt-core.

But please don't double the qt.

   Michael

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

[gentoo-dev] Re: RFC: new "qt" category

[Duncan]

Ben de Groot posted on Sat, 19 Jan 2013 22:14:48 +0800 as excerpted:

> On 19 January 2013 21:46, Patrick Lauer <patrick@gentoo.org> wrote:
>> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about
>> it?
> 
> These are libraries and applications that are used by developers of
> end-user applications.
> 
> If there is too much opposition to a simple "qt" category (at least
> there seems to be some quite vocal opposition), then dev-qt is in my
> eyes the next best alternative. A third option we came up with is
> qt-framework.
> 
> Somewhat comparable categories in the current tree are dev-dotnet and
> gnustep-{base,libs}.

Despite my interest (kde user), I've stayed out of this until now, as I 
figured there were enough others commenting and I didn't have anything 
different to say, but...

* In general, yes, I'm in favor of a dedicated qt-* category, but...

*** (VERY strongly!)  Please avoid namespace pollution!  Don't drop the 
hyphenated qt-pkg names.  As a user, most of the time I DO only refer to 
the package name, and dropping the qt- from qt-core, qt-gui, etc, is WAYYY 
too generic to be practical.  I for one would be cursing the generic 
names every time I had to deal with the package.  (Tho it's a kde 
upstream issue, the same applies to "the application formerly known as 
kcontrol", now the impossibly generic system-settings, and the former 
ksysguard, now generically system-monitor.  Anyone active on the kde 
general or kde linux lists knows I simply refuse to use the generic 
names.)

* (Less strongly.)  Please keep the hyphenated category name scheme as 
well.

* dev-qt seems appropriate.

* qt-base would work too.

* qt-libs or lib-qt, not so much, because there's executables as well.

* x11-qt not so much, as qt5 is no longer x11 limited.  Additionally, x11/
xorg will arguably start losing its dominance to wayland in the qt5 
timeframe, with qt5 even now having (preliminary?) wayland support I 
believe, and at some point, x11-qt may well look rather quaint and 
anachronistic, sort of like references to ip-chains or xfree86 do today.

So my vote would be for dev-qt/qt-*.  Yes, that's a doubled qt reference 
with the category, but in practice, few use the category name unless they 
have to anyway, and it sure beats the namespace polluting alternative!

-- 
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] RFC: new "qt" category

[Michał Górny]

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

On Thu, 17 Jan 2013 21:57:16 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> Presently we already have a good number of split qt-* library packages
> in x11-libs. With the arrival of Qt5 upstream has gone a lot further
> in modularization, so we expect the number of packages to grow much
> more. We, the Gentoo Qt team, are of the opinion that the time has
> come to split all these out into their own category. This category is
> to be used for the various modules and applications that belong to the
> upstream Qt Framework only (these include e.g. assistant and
> linguist). Third-party applications should remain in the current
> categories.
> 
> After some initial bikeshedding we came to the conclusion that naming
> the category simply "qt" is the most elegant solution. We will then
> also be dropping the qt- prefix in package names. This means
> x11-libs/qt-core will be moved to qt/core, and so on.
> 
> Please let us know your thought on this.

Just a completely different idea -- how about putting those libraries
into different categories appropriate to the topic? We have a bunch of
categories like dev-libs, media-libs, etc. -- and I wonder how many of
the Qt libs would fit into each of them.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: new "qt" category

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 19/01/13 05:56 AM, Ben de Groot wrote:
> 
> And if you really must, is emerge qt/gui so much more difficult
> than emerge qt-gui?
> 


..no, but having to specify media-libs/phonon now because qt/phonon
conflicts (just one of probably many examples) is a bit more of a pain.

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

iF4EAREIAAYFAlD687cACgkQ2ugaI38ACPARewD+OCojV9s7o/TNI8U66S9QEZKj
aMamo/OYwBw65I8A7J8A/3wi4XmgoFH+zvskCATuy0PrcMnqiIFW4i8KJBHHiV8v
=FISj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new "qt" category

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a
>> hyphen for its own sake and we're just making senseless stuff up.
>> qt-core just doesn't make sense if it applies to more than just
>> qt-core.

Wasn't "qt-framework" the classic-style category name that was
suggested in the original post? anything wrong with that?

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

iF4EAREIAAYFAlD69VEACgkQ2ugaI38ACPBUQgD/VSQ3m1zeO0k+dotPWwD4I8RK
8HoK5aWdXu0SZykvWHYA/jnx6lV9Q+qGhWWvE8WUL5UTCv/Q1sPyHuALMWQEhVja
=9yz6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new "qt" category

[Markos Chandras]

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

On Jan 19, 2013 5:19 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
>
> On Thu, 17 Jan 2013 21:57:16 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
> > Presently we already have a good number of split qt-* library packages
> > in x11-libs. With the arrival of Qt5 upstream has gone a lot further
> > in modularization, so we expect the number of packages to grow much
> > more. We, the Gentoo Qt team, are of the opinion that the time has
> > come to split all these out into their own category. This category is
> > to be used for the various modules and applications that belong to the
> > upstream Qt Framework only (these include e.g. assistant and
> > linguist). Third-party applications should remain in the current
> > categories.
> >
> > After some initial bikeshedding we came to the conclusion that naming
> > the category simply "qt" is the most elegant solution. We will then
> > also be dropping the qt- prefix in package names. This means
> > x11-libs/qt-core will be moved to qt/core, and so on.
> >
> > Please let us know your thought on this.
>
> Just a completely different idea -- how about putting those libraries
> into different categories appropriate to the topic? We have a bunch of
> categories like dev-libs, media-libs, etc. -- and I wonder how many of
> the Qt libs would fit into each of them.

Nope. These modules derive from a single tarball and it makes much more
sense to put all of them in the same place.

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

Re: [gentoo-dev] RFC: new "qt" category

[Philip Webb]

130119 Ben de Groot wrote:
> On 19 January 2013 21:46, Patrick Lauer <patrick@gentoo.org> wrote:
>> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?
> These are libraries and applications
> that are used by developers of end-user applications.

They are also encountered by users when updating KDE etc.

> If there is too much opposition to a simple "qt" category
> -- at least there seems to be some quite vocal opposition -- ,
> then dev-qt is in my eyes the next best alternative.

'qt' alone is inconsistent with the rest of the tree.

> A third option we came up with is qt-framework.

Too long to type & again no parallel in the existing tree.

> Somewhat comparable categories in the current tree
> are dev-dotnet and gnustep-{base,libs}.

Flame-eyes' suggestion is simple, consistent & involves least change :
'x11-qt/qt-core' 'x11-qt/qt-gui' etc.  Please do it like that.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] RFC: new "qt" category

[Francesco Riosa]

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

2013/1/19 Michael Weber <xmw@gentoo.org>

>
> But please don't double the qt.
>
> yay for lib-cute/qt-core

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

Re: [gentoo-dev] RFC: new "qt" category

[Francesco Riosa]

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

2013/1/19 Michał Górny <mgorny@gentoo.org>

> On Thu, 17 Jan 2013 21:57:16 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
> > Presently we already have a good number of split qt-* library packages
> > in x11-libs. With the arrival of Qt5 upstream has gone a lot further
> > in modularization, so we expect the number of packages to grow much
> > more. We, the Gentoo Qt team, are of the opinion that the time has
> > come to split all these out into their own category. This category is
> > to be used for the various modules and applications that belong to the
> > upstream Qt Framework only (these include e.g. assistant and
> > linguist). Third-party applications should remain in the current
> > categories.
> >
> > After some initial bikeshedding we came to the conclusion that naming
> > the category simply "qt" is the most elegant solution. We will then
> > also be dropping the qt- prefix in package names. This means
> > x11-libs/qt-core will be moved to qt/core, and so on.
> >
> > Please let us know your thought on this.
>
> Just a completely different idea -- how about putting those libraries
> into different categories appropriate to the topic? We have a bunch of
> categories like dev-libs, media-libs, etc. -- and I wonder how many of
> the Qt libs would fit into each of them.
>
> This would be the right thing to do, or the correct way.
Most would really hate it (me too)

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

[gentoo-dev] Re: RFC: new "qt" category

[Nikos Chantziaras]

On 17/01/13 15:57, Ben de Groot wrote:
> Presently we already have a good number of split qt-* library packages
> in x11-libs. With the arrival of Qt5 upstream has gone a lot further
> in modularization, so we expect the number of packages to grow much
> more. We, the Gentoo Qt team, are of the opinion that the time has
> come to split all these out into their own category. This category is
> to be used for the various modules and applications that belong to the
> upstream Qt Framework only (these include e.g. assistant and
> linguist). Third-party applications should remain in the current
> categories.
>
> After some initial bikeshedding we came to the conclusion that naming
> the category simply "qt" is the most elegant solution. We will then
> also be dropping the qt- prefix in package names. This means
> x11-libs/qt-core will be moved to qt/core, and so on.

Just a user with a suggestion here.  Since portage already has kde-base 
and kde-misc, why not qt-base and qt-misc (and qt-something is the need 
arises.)  Qt5 will have standard core modules and extensions.  qt-base 
and qt-misc look like they can cover these.

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 19 January 2013 23:38, Michael Weber <xmw@gentoo.org> wrote:
> We have a fixed number of exact 2 tags (foo and bar),
> This limitation has proven it's usability in the past of Gentoo, but
> there are reasons to break it up (Like making up funny points like regex
> and it has always been this way). foo-bar-baz might be usefull, too.

That's just convention, not a limitation. We already have virtual/
which breaks the convention. There is nothing, except resistance to
change, that requires us to follow the convention.

> But it's plain redundacy to in insist on *qt*/qt-*.

Agreed, though some people seem to prefer that.

> Either reject using an appropriate category and place it
> as misc-randoom/qt-* or use a category and strip the "qt-" prefix.
>
> I'm fine with qt/core, my preference would be lib-qt/core or lib/qt-core.

We don't have lib-* categories now, and I don't see why we should use
qt to start that. Besides, this whole discussion got started initially
because we were asking ourselves where to place the *applications*
(designer and linguist) that we want to split off from qt-gui and give
separate ebuilds. They are not libs, strictly spoken. So that brought
up, for us in the Qt team, that maybe it's time to have our own
category.

This is why I prefer plain "qt", or alternatively "dev-qt" or
"qt-framework". The more concise, the better.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Re: RFC: new "qt" category

[Ben de Groot]

On 20 January 2013 00:48, Duncan <1i5t5.duncan@cox.net> wrote:
> * In general, yes, I'm in favor of a dedicated qt-* category, but...

Good :-)

> *** (VERY strongly!)  Please avoid namespace pollution!  Don't drop the
> hyphenated qt-pkg names.  As a user, most of the time I DO only refer to
> the package name, and dropping the qt- from qt-core, qt-gui, etc, is WAYYY
> too generic to be practical.  I for one would be cursing the generic
> names every time I had to deal with the package.  (Tho it's a kde
> upstream issue, the same applies to "the application formerly known as
> kcontrol", now the impossibly generic system-settings, and the former
> ksysguard, now generically system-monitor.  Anyone active on the kde
> general or kde linux lists knows I simply refuse to use the generic
> names.)

And how often do you specifically emerge individual qt modules? These
are usually pulled in as dependencies, and the great majority of users
do not have to deal with this. (Just emerge smplayer, or emerge
kde-meta, or emerge -uD1 @world ...)

> * (Less strongly.)  Please keep the hyphenated category name scheme as
> well.

Why?

> * dev-qt seems appropriate.

Agreed. I think this is the next best option, if plain qt is too controversial.

> * qt-base would work too.

No, this wouldn't work. Upstream has a qtbase repo that is one of the
parts of the Qt Framework as a whole. Using qt-base as a category name
could be unnecessarily confusing.

> * qt-libs or lib-qt, not so much, because there's executables as well.

Agreed.

> * x11-qt not so much, as qt5 is no longer x11 limited.  Additionally, x11/
> xorg will arguably start losing its dominance to wayland in the qt5
> timeframe, with qt5 even now having (preliminary?) wayland support I
> believe, and at some point, x11-qt may well look rather quaint and
> anachronistic, sort of like references to ip-chains or xfree86 do today.

Agreed.

> So my vote would be for dev-qt/qt-*.  Yes, that's a doubled qt reference
> with the category, but in practice, few use the category name unless they
> have to anyway, and it sure beats the namespace polluting alternative!

Again, I don't think that should be a problem, because people would
hardly ever need to deal with qt modules directly.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 20 January 2013 05:03, Philip Webb <purslow@ca.inter.net> wrote:
> 130119 Ben de Groot wrote:
>> On 19 January 2013 21:46, Patrick Lauer <patrick@gentoo.org> wrote:
>>> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?
>> These are libraries and applications
>> that are used by developers of end-user applications.
>
> They are also encountered by users when updating KDE etc.

Not directly, only as dependencies. A simple world update will do what
is needed.

And otherwise this is more precise and concise:
    emerge -au1 `eix --only-names -IC qt`

>> If there is too much opposition to a simple "qt" category
>> -- at least there seems to be some quite vocal opposition -- ,
>> then dev-qt is in my eyes the next best alternative.
>
> 'qt' alone is inconsistent with the rest of the tree.

Not really. We already have virtual/.

>> A third option we came up with is qt-framework.
>
> Too long to type & again no parallel in the existing tree.

But closer to upstream naming.

>> Somewhat comparable categories in the current tree
>> are dev-dotnet and gnustep-{base,libs}.
>
> Flame-eyes' suggestion is simple, consistent & involves least change :
> 'x11-qt/qt-core' 'x11-qt/qt-gui' etc.  Please do it like that.

Most of Qt has nothing whatsoever to do with X11 directly, and that
will increasingly be true for Qt5 with its Wayland support.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: new "qt" category

[Ben de Groot]

On 20 January 2013 06:59, Francesco Riosa <vivo75@gmail.com> wrote:
> 2013/1/19 Michał Górny <mgorny@gentoo.org>
>> Just a completely different idea -- how about putting those libraries
>> into different categories appropriate to the topic? We have a bunch of
>> categories like dev-libs, media-libs, etc. -- and I wonder how many of
>> the Qt libs would fit into each of them.
>>
> This would be the right thing to do, or the correct way.
> Most would really hate it (me too)

Only for certain values of right and correct. Your gut reaction shows
there are other ways to look at it. Besides, do you really want to
spread the modules that are distributed in the same tarball into
different categories? And then how about updating, something
equivalent to: emerge -au1 `eix --only-names -IC qt` (or dev-qt, or
whatever the single category will be)?

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Re: RFC: new "qt" category

[Ben de Groot]

On 20 January 2013 15:59, Nikos Chantziaras <realnc@gmail.com> wrote:
> Just a user with a suggestion here.  Since portage already has kde-base and
> kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.)
> Qt5 will have standard core modules and extensions.  qt-base and qt-misc
> look like they can cover these.

There is no need for multiple qt categories. We want everything that
the upstream Qt Project considers to be part of the Qt Framework to be
in one category. Besides that there are only a handful of third-party
extensions, such as qwt. There is no need for a separate category for
those at this point in time.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[gentoo-dev] Re: RFC: new "qt" category

[Nikos Chantziaras]

On 20/01/13 10:39, Ben de Groot wrote:
> On 20 January 2013 15:59, Nikos Chantziaras <realnc@gmail.com> wrote:
>> Just a user with a suggestion here.  Since portage already has kde-base and
>> kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.)
>> Qt5 will have standard core modules and extensions.  qt-base and qt-misc
>> look like they can cover these.
>
> There is no need for multiple qt categories. We want everything that
> the upstream Qt Project considers to be part of the Qt Framework to be
> in one category. Besides that there are only a handful of third-party
> extensions, such as qwt. There is no need for a separate category for
> those at this point in time.

These are the essential modules:

   http://qt-project.org/wiki/Qt-Essentials-Modules

and these are (or will be) the add-on modules:

   http://qt-project.org/wiki/Qt-Essentials-Modules

So maybe "qt-base" and "qt-addon"?

Re: [gentoo-dev] Re: RFC: new "qt" category

[Ben de Groot]

On 20 January 2013 17:09, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 20/01/13 10:39, Ben de Groot wrote:
>> There is no need for multiple qt categories. We want everything that
>> the upstream Qt Project considers to be part of the Qt Framework to be
>> in one category. Besides that there are only a handful of third-party
>> extensions, such as qwt. There is no need for a separate category for
>> those at this point in time.
>
>
> These are the essential modules:
>
>   http://qt-project.org/wiki/Qt-Essentials-Modules
>
> and these are (or will be) the add-on modules:
>
>   http://qt-project.org/wiki/Qt-Essentials-Modules
>
> So maybe "qt-base" and "qt-addon"?

No, both the essentials and the add-ons will be in the same qt
category. There is no reason to split these into different categories.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[gentoo-dev] Re: RFC: new "qt" category

[Duncan]

Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted:

> On 20 January 2013 00:48, Duncan <1i5t5.duncan@cox.net> wrote:

>> *** (VERY strongly!)  Please avoid namespace pollution!  Don't drop the
>> hyphenated qt-pkg names.  As a user, most of the time I DO only refer
>> to the package name, and dropping the qt- from qt-core, qt-gui, etc, is
>> WAYYY too generic to be practical.  I for one would be cursing the
>> generic names every time I had to deal with the package.  (Tho it's a
>> kde upstream issue, the same applies to "the application formerly known
>> as kcontrol", now the impossibly generic system-settings, and the
>> former ksysguard, now generically system-monitor.  Anyone active on the
>> kde general or kde linux lists knows I simply refuse to use the generic
>> names.)
> 
> And how often do you specifically emerge individual qt modules? These
> are usually pulled in as dependencies, and the great majority of users
> do not have to deal with this. (Just emerge smplayer, or emerge
> kde-meta, or emerge -uD1 @world ...)

More often than one might think. =:^]

(TLDR folks feel free to skip, the summary is the line above.)

Seriously, there's occasional remerges due to USE flag changes or gcc 
upgrades and full rebuilds, there's -rX bumps, and there's the usual 
upstream version bumps.  While most of these (save for the straght-up 
same-version remerges) originally appear in emerge -NuDa, thus letting me 
know they're there, it's not unusual at all for me to pick and choose 
from the upgrade list and do bits of it at a time for one reason or 
another.

Often, the reason is because I see something changing in the upgrade 
list, and I'm not thru researching what's going on and how I might need 
to change the config to accommodate it.  I routinely check the ebuild 
changelogs for -rX bumps before I actually do the upgrade, for instance, 
because if the gentoo maintainer's doing an out-of-upstream-cycle bump 
(thus the -rX), there's generally a reason, and part of being a good 
admin is being aware at at least a general level, what's going on with 
such things, especially because they might change my desired config, or 
fix/trigger different bugs than the original package did.  Other times 
I'm still researching new USE flags, or maybe entirely new packages are 
being pulled into the depgraph, and I don't know yet what's pulling them 
in and why, when there's a reasonable chance I'll want to change USE 
flags or the like to avoid the new deps, if I can.

Thus I'll often set portage going with a subset of the full upgrade list, 
the "uninteresting" upgrades or those I've already researched, just to 
have it working on something in one terminal, while I continue doing my 
research on other package changes in another terminal window and/or in 
the browser, looking up bug-numbers, etc.

Then of course there's the times when some package or other doesn't 
build.  Given the amount of masked, overlay and prerelease packages I'm 
often running, this isn't unusual (yesterday's was plasma-workspace from 
kde 4.9.98, aka 4.10-rc3, when I was doing the .97 -> .98 upgrade; 
there's a missing extract-only, bug 450708 from 4.9.97 re-opened as it 
was fixed in that ebuild but the fix apparently didn't make it into the 
4.9.98 ebuild).  Often, I'll see it fail in the listing in one window 
(where portage is running with multiple jobs in --keep-going mode), and 
go try to remerge it in another window, letting it fail again to get the 
log, then researching and hopefully fixing the problem.  When I do, I can 
now rerun the merge for all the dependencies portage dropped due to the 
failure, sometimes while the main update is still going. =:^)

For these and other reasons it's not unusual in the least for me to be 
merging specific deep-dep packages by name.  (Of course I have -1 in my 
default emerge aliases/scripts so I don't need to worry about the world 
file getting screwed up, tho it's empty anyway as everything's in sets.)

-- 
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: RFC: new "qt" category

[Dale]

Duncan wrote:
> Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted:
>
>> On 20 January 2013 00:48, Duncan <1i5t5.duncan@cox.net> wrote:
>>> *** (VERY strongly!)  Please avoid namespace pollution!  Don't drop the
>>> hyphenated qt-pkg names.  As a user, most of the time I DO only refer
>>> to the package name, and dropping the qt- from qt-core, qt-gui, etc, is
>>> WAYYY too generic to be practical.  I for one would be cursing the
>>> generic names every time I had to deal with the package.  (Tho it's a
>>> kde upstream issue, the same applies to "the application formerly known
>>> as kcontrol", now the impossibly generic system-settings, and the
>>> former ksysguard, now generically system-monitor.  Anyone active on the
>>> kde general or kde linux lists knows I simply refuse to use the generic
>>> names.)
>> And how often do you specifically emerge individual qt modules? These
>> are usually pulled in as dependencies, and the great majority of users
>> do not have to deal with this. (Just emerge smplayer, or emerge
>> kde-meta, or emerge -uD1 @world ...)
> More often than one might think. =:^]
>
>

Same here.  I have had to re-emerge qt packages several times myself. 
It seems that when I do, I have to do them all one at a time too.

Dale

:-)  :-) 

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

Re: [gentoo-dev] Re: RFC: new "qt" category

[Ben de Groot]

On 20 January 2013 21:35, Dale <rdalek1967@gmail.com> wrote:
> Same here.  I have had to re-emerge qt packages several times myself.
> It seems that when I do, I have to do them all one at a time too.

In which case you're better off with something like:
   emerge -a1 `eix --only-names -IC qt`

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[gentoo-dev] Re: RFC: new "qt" category

[Duncan]

Ben de Groot posted on Sun, 20 Jan 2013 21:59:49 +0800 as excerpted:

> On 20 January 2013 21:35, Dale <rdalek1967@gmail.com> wrote:
>> Same here.  I have had to re-emerge qt packages several times myself.
>> It seems that when I do, I have to do them all one at a time too.
> 
> In which case you're better off with something like:
>    emerge -a1 `eix --only-names -IC qt`

FWIW, I have a qt set here.  I don't have it listed in world_sets as all 
my qt package installs are deps and I want to keep it that way, but it 
sure makes remerging them easier when I need to remerge them all. =:^)

-- 
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: RFC: new "qt" category

[Dale]

Ben de Groot wrote:
> On 20 January 2013 21:35, Dale <rdalek1967@gmail.com> wrote:
>> Same here.  I have had to re-emerge qt packages several times myself.
>> It seems that when I do, I have to do them all one at a time too.
> In which case you're better off with something like:
>    emerge -a1 `eix --only-names -IC qt`
>


I'm not a developer and I don't write fancy commands like that.  When
something needs to be emerged or re-emerged, I do it by hand. 
Sometimes, I emerge one, then emerge the next one etc etc.  Sometimes I
put all packages on the same line.  I don't use commands like yours
unless I copy and paste it from a news item or something.

Dale

:-)  :-) 

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