Re: [gentoo-dev] RFC: new qt category
On 19 January 2013 23:38, Michael Weber x...@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] RFC: new qt category
On 20 January 2013 05:03, Philip Webb purs...@ca.inter.net wrote: 130119 Ben de Groot wrote: On 19 January 2013 21:46, Patrick Lauer patr...@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
On 20 January 2013 06:59, Francesco Riosa viv...@gmail.com wrote: 2013/1/19 Michał Górny mgo...@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] RFC: new qt category
On 17 January 2013 22:45, Diego Elio Pettenò flamee...@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
On Sat, Jan 19, 2013 at 11:56 AM, Ben de Groot yng...@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
On Sat, Jan 19, 2013 at 7:43 AM, Diego Elio Pettenò flamee...@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
On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman ri...@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
On 01/19/2013 09:39 PM, Diego Elio Pettenò wrote: On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman ri...@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
On Sat, Jan 19, 2013 at 8:46 AM, Patrick Lauer patr...@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
On 19 January 2013 21:46, Patrick Lauer patr...@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
On 01/19/2013 03:14 PM, Ben de Groot wrote: On 19 January 2013 21:46, Patrick Lauer patr...@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 x...@gentoo.org
Re: [gentoo-dev] RFC: new qt category
On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new qt category
-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman ri...@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
On Jan 19, 2013 5:19 PM, Michał Górny mgo...@gentoo.org wrote: On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@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.
Re: [gentoo-dev] RFC: new qt category
130119 Ben de Groot wrote: On 19 January 2013 21:46, Patrick Lauer patr...@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
2013/1/19 Michael Weber x...@gentoo.org But please don't double the qt. yay for lib-cute/qt-core
Re: [gentoo-dev] RFC: new qt category
2013/1/19 Michał Górny mgo...@gentoo.org On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@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)
Re: [gentoo-dev] RFC: new qt category
On 18 January 2013 04:24, Mike Frysinger vap...@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
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new qt category
2013/1/17 Ben de Groot yng...@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/
[gentoo-dev] RFC: new qt category
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
Much nicer naming IMHO. +1 from me.
Re: [gentoo-dev] RFC: new qt category
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: new qt category
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
-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 alexan...@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-
Re: [gentoo-dev] RFC: new qt category
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
On 17 January 2013 22:05, Diego Elio Pettenò flamee...@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
On 17 January 2013 22:09, Chí-Thanh Christopher Nguyễn chith...@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] RFC: new qt category
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
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: new qt category
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
On Thu, 17 Jan 2013 15:05:53 +0100 Diego Elio Pettenò flamee...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new qt category
CM == Ciaran McCreesh ciaran.mccre...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new qt category
On Thu, 17 Jan 2013 12:05:03 -0500 James Cloos cl...@jhcloos.com wrote: CM == Ciaran McCreesh ciaran.mccre...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new qt category
BdG == Ben de Groot yng...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new qt category
On Thu, 17 Jan 2013 12:03:36 -0500 James Cloos cl...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new qt category
On Thu, Jan 17, 2013 at 12:14 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 17 Jan 2013 12:03:36 -0500 James Cloos cl...@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
-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
CM == Ciaran McCreesh ciaran.mccre...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new qt category
On Thu, 17 Jan 2013 14:35:12 -0500 James Cloos cl...@jhcloos.com wrote: CM == Ciaran McCreesh ciaran.mccre...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new qt category
2013/1/17 Chris Reffett creff...@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
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 dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: new qt category
On Thu, Jan 17, 2013 at 2:46 PM, Andreas K. Huettel dilfri...@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 dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] RFC: new qt category
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 signature.asc Description: This is a digitally signed message part.