Hi, the x11-libs/qt-meta package is just for convenience and developers MUST not add it as {R}DEPEND on their ebuilds. They should depend on split ebuilds instead. Could you please add a repoman warning, so developers who are not aware of that, wont make that mistake? I would rather this being a fatal warning and don't let them commit their ebuilds until they fix it. This was discussed and agreed by the rest of the Qt team members
Is there really much risk of this happening? We've had a similar repoman check for virtual/x11 in the past, but that was more necessary because having virtual/x11 as a dependency was a common practice at the time.
Old developers are well educated to not depend on the meta package, but new devs may do it an create a whole mess for users. I think the check is needed ( if it is not too much trouble of course )
I suggest we add the "qt4" set to portage then last-rite qt-meta.
(In reply to Michael Palimaka (kensington) from comment #3) Yes, BUT: 1/ we cannot really remove qt-meta because, as has been pointed out on -dev, sets are portage-specific, therefore users of other PMs would see a regression. 2/ how can we handle package sets that vary over time? More specifically, how can we express the fact that the qt4 set for 4.8.5 has more packages than the set for 4.8.4? 3/ how do we implement the dev-qt/qtphonon vs. media-libs/phonon choice? (we have some more USE flags in qt-meta currently but phonon is the most critical one IMO)
I guess it is not really a good candidate for a set then.
(In reply to Davide Pesavento from comment #4) > 1/ we cannot really remove qt-meta because, as has been pointed out on -dev, > sets are portage-specific, therefore users of other PMs would see a > regression. I don't see a problem here, because the meta was just for convenience, not something we recommend using, and definitely not something essential that users of obscure PMs would miss. > 2/ how can we handle package sets that vary over time? More specifically, > how can we express the fact that the qt4 set for 4.8.5 has more packages > than the set for 4.8.4? This is more of a problem. Given the main target of the meta (people who want all of Qt because they need it for development), I would say it makes most sense to follow the latest release, and include all the packages of that release, and update the set as necessary with each new release. Or we could make sets for qt4-stable and qt4-latest. > 3/ how do we implement the dev-qt/qtphonon vs. media-libs/phonon choice? (we > have some more USE flags in qt-meta currently but phonon is the most > critical one IMO) We decided to drop support for qtphonon.
(In reply to Ben de Groot from comment #6) > (In reply to Davide Pesavento from comment #4) > > 1/ we cannot really remove qt-meta because, as has been pointed out on -dev, > > sets are portage-specific, therefore users of other PMs would see a > > regression. > > I don't see a problem here, because the meta was just for convenience, not > something we recommend using, and definitely not something essential that > users of obscure PMs would miss. > Fair enough. It's still a regression though. > > 2/ how can we handle package sets that vary over time? More specifically, > > how can we express the fact that the qt4 set for 4.8.5 has more packages > > than the set for 4.8.4? > > This is more of a problem. Given the main target of the meta (people who > want all of Qt because they need it for development), I would say it makes > most sense to follow the latest release, and include all the packages of > that release, and update the set as necessary with each new release. Or we > could make sets for qt4-stable and qt4-latest. > Only following the latest release is not acceptable because it would make the set unusable for stable users. qt4-stable and qt4-latest makes more sense, but it's kinda ugly and doesn't allow us to have more than 1 stable and 1 testing versions at the same time. > > 3/ how do we implement the dev-qt/qtphonon vs. media-libs/phonon choice? (we > > have some more USE flags in qt-meta currently but phonon is the most > > critical one IMO) > > We decided to drop support for qtphonon. It's not that easy unfortunately. Deciding to drop it does not magically make it disappear from the tree and fix all reverse deps. And afaik nobody's working on it. But even if qtphonon was gone, what about the other USE flags? On the other hand, what are the advantages of a set?
(In reply to Davide Pesavento from comment #7) > > > 2/ how can we handle package sets that vary over time? More specifically, > > > how can we express the fact that the qt4 set for 4.8.5 has more packages > > > than the set for 4.8.4? > > > > This is more of a problem. Given the main target of the meta (people who > > want all of Qt because they need it for development), I would say it makes > > most sense to follow the latest release, and include all the packages of > > that release, and update the set as necessary with each new release. Or we > > could make sets for qt4-stable and qt4-latest. > > > > Only following the latest release is not acceptable because it would make > the set unusable for stable users. > > qt4-stable and qt4-latest makes more sense, but it's kinda ugly and doesn't > allow us to have more than 1 stable and 1 testing versions at the same time. The set will not be correct in the time between the first and last arch do their stabilisation. > > > 3/ how do we implement the dev-qt/qtphonon vs. media-libs/phonon choice? (we > > > have some more USE flags in qt-meta currently but phonon is the most > > > critical one IMO) > > > > We decided to drop support for qtphonon. > > It's not that easy unfortunately. Deciding to drop it does not magically make > it disappear from the tree and fix all reverse deps. And afaik nobody's working on it. I forgot completely about this, so I added a new page to the wiki about it: https://wiki.gentoo.org/wiki/Project:Qt/Ongoing_tasks
@portage/qa, please comment if you accept this check. If so, I'll send a patch, otherwise we can close the bug.
(In reply to Michael Palimaka (kensington) from comment #9) > @portage/qa, please comment if you accept this check. If so, I'll send a > patch, otherwise we can close the bug. <ulm> kensington: I don't think that we should hardcode specific package atoms in repoman <ulm> at least we should keep this limited to exceptional cases <kensington> ulm: i have no particular opinion about this check, but there is a number of checks around specific atoms in dependency strings <ulm> kensington: I see virtual/jdk and x11-libs/wxGTK there <ulm> doesn't imply that we add more such special cases, though <kensington> ulm: do you mind to leave a comment? I'm keen to close this old bug either way
I also agree that individual specific dep checks should not be in repoman. However, if we added a generic dep check that reads a file of pkgs that should not be used in *DEPEND. That way the check is generic, easily updated, cleaned. Stick the file in the profiles with a date/Dev name like a package.mask entry. It is then circulated with the tree, constantly refreshed,... Set an expirey of 1 year or so for them to be cleaned. That should give enough time for the tree ebuilds to be cleaned, and keep the file content to a minimum.
The devmanual states that it is an error to depend on a meta package: https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html So we could add a repoman check for package names ending in -meta.
Such new check should not be performed in *-meta packages themselves. E.g. kde-base/kdebase-meta depends on kde-base/kdebase-runtime-meta, while kde-base/kde-meta depends on all other kde-base/kde?*-meta packages.
Also there are packages named *-meta that are not metapackages, but where the -meta is part of the upstream package name, e.g. dev-haskell/haskell-src-meta, so an additonal check (e.g. for empty SRC_URI) would be needed.
(In reply to Ulrich Müller from comment #14) > Also there are packages named *-meta that are not metapackages, but where > the -meta is part of the upstream package name, e.g. > dev-haskell/haskell-src-meta, so an additonal check (e.g. for empty SRC_URI) > would be needed. And then there's -9999 ebuilds that have empty SRC_URI anyway. We've got PROPERTIES and RESTRICT variables that we can use to tag meta packages as meta packages.
That brings me back to re-mentioning my idea for a generic check that sources the pkgs list from a file in profiles. see comment 11
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
