[gentoo-dev] blocking mixed versions of split QT libraries
QT doesn't work well when mixed versions of its core libraries are
installed. Usually an emerge -avDu world solves the problem, but some
users tend to avoid this.
For example, lets say you have parts of QT 4.4.2 on your system. QT
4.5.1 is available and a user decides to manually update qt-core, or
to install KDE which has a QT dependency on a QT library not
installed. In these cases, portage will update only a part of the
installed QT libraries, leaving the system in a mixed state.
QT based apps don't like that. Others will refuse to build, others
will fail to run.
We've managed to experimentally block partial QT upgrades by adding an
RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
understands this and throws out B blocks if you try to change versions
only in parts of QT, but upgrades/downgrades fine if you do them all
at once (or use -Du world).
This fix also catches stale QT libraries that nothing depends on
anymore because the user has removed whatever required them (and never
ran --depclean).
Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.
What I'd like to discuss is the following:
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy please -Du world?
We've also managed to achieve the same thing by adding PDEPENDs to
each QT library for any other QT libraries that depend on it:
i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
PDEPEND=
|| ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
the above (expanded for all libraries) has the same effect as the [1]
RDEPEND but looks a bit more hackish.
thanks
[1] lines 30-59
http://github.com/gentoo-qt/qting-edge/blob/master/eclass/qt4-build-edge.eclass
--
Alex Alexander || wired
Gentoo QT KDE Herd Tester
http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
Alex Alexander wrote:
QT doesn't work well when mixed versions of its core libraries are
installed. Usually an emerge -avDu world solves the problem, but some
users tend to avoid this.
For example, lets say you have parts of QT 4.4.2 on your system. QT
4.5.1 is available and a user decides to manually update qt-core, or
to install KDE which has a QT dependency on a QT library not
installed. In these cases, portage will update only a part of the
installed QT libraries, leaving the system in a mixed state.
QT based apps don't like that. Others will refuse to build, others
will fail to run.
We've managed to experimentally block partial QT upgrades by adding an
RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
understands this and throws out B blocks if you try to change versions
only in parts of QT, but upgrades/downgrades fine if you do them all
at once (or use -Du world).
This fix also catches stale QT libraries that nothing depends on
anymore because the user has removed whatever required them (and never
ran --depclean).
Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.
From what I understand you are utilizing portages ability to
automagically resolve blockers when all blockers will be resolved within
the current command. Agree?? or is it the fact that you are doing
!x11-libs/qt-assistant-${PV}-r that is causing the paludis problem?
I would suggest that you just tell paludis users to use --dl-blocks
discard when updating qt. After looking at the eclass im not sure
whether it will work or not. im assuming that discarding blocks will
just ignore everything, but I haven't tested it so can't be sure.
What I'd like to discuss is the following:
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
I don't believe so, not within current ways of declaring dependencies.
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy please -Du world?
I say we should be stopping them from happening.
We've also managed to achieve the same thing by adding PDEPENDs to
each QT library for any other QT libraries that depend on it:
i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
PDEPEND=
|| ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
the above (expanded for all libraries) has the same effect as the [1]
RDEPEND but looks a bit more hackish.
And I would agree with the hackish comment.
thanks
Good work btw.
Alistair.
Re: [gentoo-dev] GLEP 54 and hyphens in PV
On Mon, 18 May 2009 06:59:36 +0200 Ulrich Mueller u...@gentoo.org wrote: AFAICS, there _is_ an ambiguity. There's no ambiguity. It means what we define it to mean. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 13:04:27 +0300
Alex Alexander alex.alexan...@gmail.com wrote:
Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.
Paludis treats blocks as strong, the way Portage used to and the way
PMS defined them until we had to retroactively change it to allow
Portage's newer behaviour...
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
Not really. There's no particularly good mechanism for ensuring equal
versions of things where not everything has to be installed. The best
option I can think of is to have a meta package called, say, split-qt,
and to do all your external (not inter-qt-library) dependencies as:
x11-libs/split-qt[gui][xmlpatterns]
and then have x11-libs/split-qt's deps be like:
gui? ( ~x11-libs/qt-gui-${PV} )
2) Is our implementation considered correct and acceptable by the PMS
guys?
The way PMS defines blockers has been rewritten to allow both what
Portage used to do and what Portage now does. It's fairly horrible, but
unfortunately Zac changed Portage's behaviour (breaking anything that
relied upon strong blockers, hence the quickly-hacked-in !! blocker
hack) without EAPI control.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
Ciaran McCreesh wrote: On Mon, 18 May 2009 13:04:27 +0300 Alex Alexander alex.alexan...@gmail.com wrote: Unfortunately we've got reports from paludis users stating that they can't update QT from qting-edge anymore. Paludis treats blocks as strong, the way Portage used to and the way PMS defined them until we had to retroactively change it to allow Portage's newer behaviour... Unfortunate but what does this have to do with the original question? EAPI 2 moved to the new soft behavior and as far as I know all qt ebuilds are EAPI 2. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 17:47:52 +0300 Petteri Räty betelge...@gentoo.org wrote: Ciaran McCreesh wrote: On Mon, 18 May 2009 13:04:27 +0300 Alex Alexander alex.alexan...@gmail.com wrote: Unfortunately we've got reports from paludis users stating that they can't update QT from qting-edge anymore. Paludis treats blocks as strong, the way Portage used to and the way PMS defined them until we had to retroactively change it to allow Portage's newer behaviour... Unfortunate but what does this have to do with the original question? EAPI 2 moved to the new soft behavior and as far as I know all qt ebuilds are EAPI 2. The definition of soft behaviour allows soft blockers to be treated identically to hard blockers. We had to do it this way because Portage's rules for soft blockers are too fuzzy and arbitrary to turn into a formal specification -- they were a code first, think later solution with which we can't do anything useful. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 55 updated
Joe Peterson wrote: Ciaran McCreesh wrote: 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. I actually like the current format in that it does *not* allow - in the version. For example, pkg-2.3.1_rc5 makes it clear that the string from 2 to rc5 is the version. If were were to allow pkg-2.3.1-rc5, this could get visually confusing (looks a bit like pkg-2.3.1-r5). In this case, *less* flexibility and more strict rules serve a good purpose, I think. Agreed; the purpose of an internal format specification is not to allow NN variants on a theme all over the place. It should nail things down to ONE variant which everybody can collaborate around. I missed the clamour of developers complaining about this oh-so-burdensome restriction that they've been dealing with for at least 5 years. Until I see that happening independently of this current hooha, I'm going to consider this 'reason' to be yaf straw man. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 16:07:20 +0100 Steven J Long sl...@rathaus.eclipse.co.uk wrote: I missed the clamour of developers complaining about this oh-so-burdensome restriction that they've been dealing with for at least 5 years. Why do you think I wrote the awful hack that is versionator? Anything that finally lets us kill that off has to be good... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. Anything that finally lets us kill that off has to be good... Loosening VERSION requirements won't fix the problem. This will: 1) Discourage its use by putting a QA ewarn in the eclass. 2) Have all ebuilds converted either through QA bugs or a nice Saturday afternoon coding spree. 3) Announce its removal. 4) Remove.
[gentoo-dev] Re: GLEP 55 updated
David Leverton wrote: 2009/5/17 Ben de Groot yng...@gentoo.org: I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure. Ugh. Firstly versionator is a piece of bloated crap that should have died a long time ago; all it does is stop Gentoo newbs learning the basics[1] of their implementation language, which leaves them open to nonsensical arguments about printf -v (glad you finally learnt that one, btw.) Secondly, please explain fully and clearly, but concisely, why we can't simply state that EAPI=NN allows the ebuild to use the EAPI functions in global scope. Bear in mind that you have to deal with the case of the mangler which can get EAPI from an ebuild without sourcing, as portage currently can, I believe. Relaxing that restriction strikes me as much saner than relaxing all the other restrictions which make interoperability easier. (Frankly, I'm amazed at having to state that to people trusted to write a specification. Follow up to -project on this point please, as it's about process, not technique.) [1] (watch wrap) http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02 http://wooledge.org/mywiki/BashFAQ/073 man bash /Parameter Expansion -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: GLEP 55 updated
Ciaran McCreesh wrote: On Mon, 18 May 2009 16:07:20 +0100 Steven J Long sl...@rathaus.eclipse.co.uk wrote: I missed the clamour of developers complaining about this oh-so-burdensome restriction that they've been dealing with for at least 5 years. Why do you think I wrote the awful hack that is versionator? Anything that finally lets us kill that off has to be good... I have to disagree. As Steve said, the fact that Gentoo has a strict way to specify versions brings clarity and uniformity to our tree, regardless of the myriad upstream conventions. I do not think that allowing all of those upstream conventions in our filenames is a benefit. It is actually quite ugly and would make the tree harder to comprehend. Someone looking at various packages in our tree would need to learn each specific upstream format in order to make sense of the filename content. The current consistency in versions in the tree is a great feature, IMHO. Using versionator and $MY_PV is, as I see it, a translation method. It gives us the best of both worlds: the ability to deal with upstream versions and a consistent Gentoo version format. These mechanisms could certainly be improved upon, of course, and handling some cases is currently difficult, as is handing the case in which upstream's tarball file does not contain the version, but these are fixable issues. -Joe
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 17:28:00 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. Versionator was created because the alternative was worse: developers were hard-coding versions in ebuilds, writing dodgy bash substitutions that wouldn't reliably convert between versions and using things like sed and tr in global scope. The problem is, versionator was written before the current version rules. It doesn't handle some things that are now legal, and it still uses the old meanings for numeric components. The correct solution is two-fold: * Replace versionator with package-manager internal functions that use the package manager's rules for version parsing. * Reduce the need to use MY_PV by extending the version rules. Both of these are things that can't be done with current EAPI rules. Anything that finally lets us kill that off has to be good... Loosening VERSION requirements won't fix the problem. This will: 1) Discourage its use by putting a QA ewarn in the eclass. 2) Have all ebuilds converted either through QA bugs or a nice Saturday afternoon coding spree. 3) Announce its removal. 4) Remove. You can't discourage versionator until the replacement's in place. Going back to the old way of doing things is a loot worse than using versionator. So no, the way to fix it is: 1) Change the EAPI rules to allow global scope and version suffix changes. 2) Bring in a versionator replacement done as internals in a new EAPI. 3) Extend the version format rules in a new EAPI. 4) Disallow versionator use in the first EAPI that has 2) and 3). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Monday 18 May 2009, Jeroen Roovers wrote: On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. I'm not following. Why should it be discouraged? I was happy with it until now. Robert signature.asc Description: This is a digitally signed message part.
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 17:42:19 +0200 Robert Buchholz r...@gentoo.org wrote: I'm not following. Why should it be discouraged? I was happy with it until now. Versionator is a lot better than what people were doing before I wrote it. It's just nowhere near as good as what a package manager provided solution combined with a reduced need for MY_PV hacks would give. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55 updated
2009/5/18 Steven J Long sl...@rathaus.eclipse.co.uk: David Leverton wrote: 2009/5/17 Ben de Groot yng...@gentoo.org: I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure. Ugh. Firstly versionator is a piece of bloated crap that should have died a long time ago; all it does is stop Gentoo newbs learning the basics[1] of their implementation language, which leaves them open to nonsensical arguments about printf -v (glad you finally learnt that one, btw.) Yes, it should have died a long time ago, that's why we're talking about adding equivalent built-in functionality. Please try to keep up. (And it's always amusing to see your bizarre delusions about what I do and don't know.) Secondly, please explain fully and clearly, but concisely, why we can't simply state that EAPI=NN allows the ebuild to use the EAPI functions in global scope. Because by the time the package manager knows the EAPI and is in a position to provide the appropriate functions, the ebuild will have already tried to use them. Bear in mind that you have to deal with the case of the mangler which can get EAPI from an ebuild without sourcing, as portage currently can, I believe. Interesting Relaxing that restriction strikes me as much saner than relaxing all the other restrictions which make interoperability easier. (Frankly, I'm amazed at having to state that to people trusted to write a specification. Follow up to -project on this point please, as it's about process, not technique.) You're amazed that people trusted to write a specification don't already know what strikes you as much saner? Believe it or not, the world does not revolve around you and your opinions.
Re: [gentoo-dev] blocking mixed versions of split QT libraries
From what I understand you are utilizing portages ability to
automagically resolve blockers when all blockers will be resolved within
the current command. Agree?? or is it the fact that you are doing
!x11-libs/qt-assistant-${PV}-r that is causing the paludis problem?
Yes, portage's auto-resolving ability thats exactly what we're using
to make this happen.
I would suggest that you just tell paludis users to use --dl-blocks
discard when updating qt. After looking at the eclass im not sure
whether it will work or not. im assuming that discarding blocks will
just ignore everything, but I haven't tested it so can't be sure.
Well since there's no other obvious way to achieve the whole thing,
this seems like the only option for paludis users for now. If it
works.
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
I don't believe so, not within current ways of declaring dependencies.
maybe the PMS guys could implement something... :D
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy please -Du world?
I say we should be stopping them from happening.
Good work btw.
Thank you for your thoughts
--
Alex Alexander || wired
Gentoo QT KDE Herd Tester
http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, May 18, 2009 at 17:21, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
Not really. There's no particularly good mechanism for ensuring equal
versions of things where not everything has to be installed. The best
option I can think of is to have a meta package called, say, split-qt,
and to do all your external (not inter-qt-library) dependencies as:
x11-libs/split-qt[gui][xmlpatterns]
and then have x11-libs/split-qt's deps be like:
gui? ( ~x11-libs/qt-gui-${PV} )
how would that solve a user's emerge -av1 qt-core when a new Qt
version becomes available?
--
Alex Alexander || wired
Gentoo QT KDE Herd Tester
http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, May 18, 2009 at 19:51, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: It wouldn't, although it would be fixed as soon as someone tried to install a package with a Qt dep. Dependencies the way they are now aren't really expressive enough to handle what you're after -- split packages are considered unrelated. so the RDEPEND in qting-edge seems to be the only working solution for now... is paludis expected to behave like portage in the near future regarding these blocks? are there any plans to add support for these kinds of cases in the PMS? other sets of packages could probably benefit from such a feature as well. thanks -- Alex Alexander || wired Gentoo QT KDE Herd Tester http://www.linuxized.com
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 20:01:22 +0300 Alex Alexander alex.alexan...@gmail.com wrote: is paludis expected to behave like portage in the near future regarding these blocks? Probably not. My issue with the way Portage does soft blocks is that it's way too arbitrary, fuzzy and ill defined. There were plans to do blocks properly (include annotations that would let the developer tell the package manager to point the user to a URL explaining the block and how to resolve it) back before Zac went and did his own thing. One of the goals was to tell the package manager exactly what was meant by the block, allowing the package manager to come up with a much more sensible and far less dangerous solution. If those plans are ever revived, Paludis would support them. are there any plans to add support for these kinds of cases in the PMS? other sets of packages could probably benefit from such a feature as well. I don't recall any existing discussion about such a feature (beyond me moaning in pre-EAPI days about vim/gvim/vim-core breaking in the same way Qt does). So... The way to start is probably by identifying the problem in detail, and identifying other groups of packages affected by similar issues, so we can work out what exactly it is we'd be looking to fix. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 19:15:59 +0200 Maciej Mrozowski reave...@poczta.fm wrote: Not sure who is 'we' there, but Portage team already made is useful. Basic portage rule for soft-blocks behaviour is no longer referenced (a'ka 'soft') blocked package can be uninstalled cleanly without user intervention That's not in the least bit well defined, and it's also extremely dangerous. Zac did good job there saving users (especially KDE users) from nightmare of handling all package refactoring/blocks manually. The nightmare only existed because of abuse of that feature. Had blocks kept their original meaning, people would not have abused them to the same extent. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Monday 18 of May 2009 19:26:58 Ciaran McCreesh wrote: On Mon, 18 May 2009 19:15:59 +0200 Maciej Mrozowski reave...@poczta.fm wrote: Not sure who is 'we' there, but Portage team already made is useful. Basic portage rule for soft-blocks behaviour is no longer referenced (a'ka 'soft') blocked package can be uninstalled cleanly without user intervention That's not in the least bit well defined, and it's also extremely dangerous. Please elaborate on that. (to make it simple, let me use portage terminology below) Everything what user should be interested in is expected to be in 'world' file or 'world_sets' or pulled as dependencies. This I define by referenced. Everything else like things installed temporarily, no longer pulled packages, are subject of 'depclean'. I don't see why pruning those you consider extremely dangerous - especially when there are parameters like --pretend or --ask. While no longer referenced term may be considered not fully defined as it does not specify the way things become not referenced anymore (as packages may be determined to be referenced later, during block resolution stage, but that's implementation specific) - the term referenced is defined well enough. Nobody is (for now) expecting every PMS compliant package manager to return identical dependency graph in corner cases. Zac did good job there saving users (especially KDE users) from nightmare of handling all package refactoring/blocks manually. The nightmare only existed because of abuse of that feature. Had blocks kept their original meaning, people would not have abused them to the same extent. Unfortunately in packaging of dynamically developed applications like whole KDE environment (with Gentoo KDE split package policy - ~250 ebuilds with every release) it's impossible not to 'abuse' blocks - either to handle file collisions issues, or removed/moved libraries (by upstream). Not sure what was original meaning of blocks you're referring to, either way - there is no rule stating = N uses of feature X in scope Y in time frame T is considered abuse - that being said, I'm surprised you're looking for cheap excuse for providing no working block auto-resolution mechanism (or maybe there is some I'm not aware of) - it does not need to be in any Gentoo specification after all - just to make things easier for users. -- regards MM -- Zrob sobie prezent. Wygraj nagrode! Sprawdz http://link.interia.pl/f2176
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 20:05:51 +0200 Maciej Mrozowski reave...@poczta.fm wrote: That's not in the least bit well defined, and it's also extremely dangerous. Please elaborate on that. With Portage's soft blocks, there's no guarantee that your blocks will do anything at all. Soft blocks are ignored if they'll be fixed later, but then there's no guarantee that later will be reached. Everything else like things installed temporarily, no longer pulled packages, are subject of 'depclean'. I don't see why pruning those you consider extremely dangerous - especially when there are parameters like --pretend or --ask. It's unrealistic to assume that depclean's going to be accurate at every given moment, especially given Portage's massively overoptimistic treatment of slots. It's also a very bad idea to remove packages without the user explicitly giving permission to do so. Zac did good job there saving users (especially KDE users) from nightmare of handling all package refactoring/blocks manually. The nightmare only existed because of abuse of that feature. Had blocks kept their original meaning, people would not have abused them to the same extent. Unfortunately in packaging of dynamically developed applications like whole KDE environment (with Gentoo KDE split package policy - ~250 ebuilds with every release) it's impossible not to 'abuse' blocks - either to handle file collisions issues, or removed/moved libraries (by upstream). Not sure what was original meaning of blocks you're referring to, either way - there is no rule stating = N uses of feature X in scope Y in time frame T is considered abuse Blocks are supposed to be an absolute last resort, not something you throw around willy-nilly to try to get Portage to do what you're after. - that being said, I'm surprised you're looking for cheap excuse for providing no working block auto-resolution mechanism (or maybe there is some I'm not aware of) - it does not need to be in any Gentoo specification after all - just to make things easier for users. Bah. I'm looking for a way of doing this properly, as I was before Zac went and broke blockers in Portage. Such a way would: * work by explaining the reason for the blocker, rather than sort-of stating the expected resolution. * provide mechanisms for explaining the block in detail to the user, along with instructions on how to resolve it. * be based around tree requirements, not some side effects of some code someone happened to write without considering the implications. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Monday 18 May 2009 20:19:24 Ciaran McCreesh wrote: On Mon, 18 May 2009 20:05:51 +0200 Maciej Mrozowski reave...@poczta.fm wrote: That's not in the least bit well defined, and it's also extremely dangerous. Please elaborate on that. With Portage's soft blocks, there's no guarantee that your blocks will do anything at all. Soft blocks are ignored if they'll be fixed later, but then there's no guarantee that later will be reached. In terms of the on-disk result it's invariant, the result is what you'd expect. There are intermediate stages that are inconsistent / unclean, but as these are known and temporary they are an acceptable solution. Everything else like things installed temporarily, no longer pulled packages, are subject of 'depclean'. I don't see why pruning those you consider extremely dangerous - especially when there are parameters like --pretend or --ask. It's unrealistic to assume that depclean's going to be accurate at every given moment, especially given Portage's massively overoptimistic treatment of slots. It's also a very bad idea to remove packages without the user explicitly giving permission to do so. Which either means that the deps are wrong/incomplete or that portage has algorithmic flaws which should be corrected. I'd expect you to at least point to the relevant bugs and not just state some emotional mumbo-jumbo. Plus the packages that are removed were not installed explicitly, and to satisfy the needs of the user they are removed. This reflects the demands of the user (Give me this app! or Update this pile of apps!) quite well. Blocks are supposed to be an absolute last resort, not something you throw around willy-nilly to try to get Portage to do what you're after. No, blocks are what you need to keep the set of installed packages consistent. They need to be used as much as the flaws and conflicts of software packaging require. Any emotional statement like last resort, obviously, willy-nilly or cute has no place in a discussion about needed technical features. - that being said, I'm surprised you're looking for cheap excuse for providing no working block auto-resolution mechanism (or maybe there is some I'm not aware of) - it does not need to be in any Gentoo specification after all - just to make things easier for users. Bah. I'm looking for a way of doing this properly, as I was before Zac went and broke blockers in Portage. s/broke/fixed/ Such a way would: * work by explaining the reason for the blocker, rather than sort-of stating the expected resolution. That's dumb ;) (Sorry, emotional statement) I mean, it does not help to solve the issue and requires user interaction where an automated solution has been working reliably for quite some time. Providing extra information would be nice, but causes more work for the package maintainer and the user for little benefit. * provide mechanisms for explaining the block in detail to the user, along with instructions on how to resolve it. User interaction where automated resolution works sounds like a step backwards to me. Maybe refining the rules for automated resolution would be a more appropriate solution? * be based around tree requirements, not some side effects of some code someone happened to write without considering the implications. What is a tree requirement? (Nice buzzword btw) And as many devs and users benefit quite a lot from the portage solution, which zmedico did not dream up without thinking about the impact on users, I find it very rude and condescending of you to disrespect the solution without offering an alternative. As you seem to understand the problem domain I'd expect a coherent unambiguous proposal instead of vague accusations and emotional terms that do not help in any way to improve the situation.
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 21:08:25 +0200 Patrick Lauer patr...@gentoo.org wrote: In terms of the on-disk result it's invariant, the result is what you'd expect. There are intermediate stages that are inconsistent / unclean, but as these are known and temporary they are an acceptable solution. No, they're temporary except when things go wrong, at which point there's no indication that they'll be fixed. It's unrealistic to assume that depclean's going to be accurate at every given moment, especially given Portage's massively overoptimistic treatment of slots. It's also a very bad idea to remove packages without the user explicitly giving permission to do so. Which either means that the deps are wrong/incomplete or that portage has algorithmic flaws which should be corrected. I'd expect you to at least point to the relevant bugs and not just state some emotional mumbo-jumbo. Look at the new slot deps in EAPI 3. Bah. I'm looking for a way of doing this properly, as I was before Zac went and broke blockers in Portage. s/broke/fixed/ No, broke. What he did was in direct violation of PMS and in direct violation of assumptions made by many packages. * work by explaining the reason for the blocker, rather than sort-of stating the expected resolution. That's dumb ;) (Sorry, emotional statement) I mean, it does not help to solve the issue and requires user interaction where an automated solution has been working reliably for quite some time. Uhm. Knowing the reason for the block lets the package manager solve the problem in the most intelligent available way. Merely being sort-of told the expected resolution does not. * provide mechanisms for explaining the block in detail to the user, along with instructions on how to resolve it. User interaction where automated resolution works sounds like a step backwards to me. Maybe refining the rules for automated resolution would be a more appropriate solution? Automated resolution is not always possible or a good idea. Also, having more information available for the user and being able to suggest an automated resolution are not in the least bit contradictory. * be based around tree requirements, not some side effects of some code someone happened to write without considering the implications. What is a tree requirement? (Nice buzzword btw) A tree requirement is one that comes about as a result of studying what ebuilds do now and what they'd like to do in the future, rather than one that comes around based upon what someone happens to code. And as many devs and users benefit quite a lot from the portage solution, which zmedico did not dream up without thinking about the impact on users, I find it very rude and condescending of you to disrespect the solution without offering an alternative. ...except for the things that it broke, which necessitated shoving !! blocks in at the last minute. And I'll remind you that there were discussions about a proper blocker solution before Zac went and did his thing, and the overwhelming view was that a solution based around the things I've been discussing was what was wanted. As you seem to understand the problem domain I'd expect a coherent unambiguous proposal instead of vague accusations and emotional terms that do not help in any way to improve the situation. See the discussions we had back when the only kind of blocker was a hard, single ! block. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Monday 18 May 2009 21:20:10 Ciaran McCreesh wrote: On Mon, 18 May 2009 21:08:25 +0200 Patrick Lauer patr...@gentoo.org wrote: In terms of the on-disk result it's invariant, the result is what you'd expect. There are intermediate stages that are inconsistent / unclean, but as these are known and temporary they are an acceptable solution. No, they're temporary except when things go wrong, at which point there's no indication that they'll be fixed. When things go wrong they go wrong. Indeed. At the moment I can't think of an obvious failure mode, so I guess I'll have to wait for you to refresh my memory. Until then I'll just be happy that KDE, poppler, e2fsprogs and a few other apps refused to fail and saved me lots of time and trouble (and some failure modes that are really frustrating) by just magically upgrading in the right sequence, avoiding error-prone user interaction (e2fsprogs had one funny bug that a few hundred users found) and allowing me to be a lazy cat. It's unrealistic to assume that depclean's going to be accurate at every given moment, especially given Portage's massively overoptimistic treatment of slots. It's also a very bad idea to remove packages without the user explicitly giving permission to do so. Which either means that the deps are wrong/incomplete or that portage has algorithmic flaws which should be corrected. I'd expect you to at least point to the relevant bugs and not just state some emotional mumbo-jumbo. Look at the new slot deps in EAPI 3. So the deps were not precise enough, and now we improve that. Which means that portage will only get more precise in the future. Awesome! No, broke. What he did was in direct violation of PMS and in direct violation of assumptions made by many packages. So PMS did once again not reflect reality, and there were some buggy packages. Maybe we should spend more time on making PMS a standard that documents current and past behavior instead of omitting things (mtime, bash 3.1) or keeping it ambiguous so that two implementations can be compliant while delivering incompatible results? And then ... well ... bugs are there to be fixed. * work by explaining the reason for the blocker, rather than sort-of stating the expected resolution. That's dumb ;) (Sorry, emotional statement) I mean, it does not help to solve the issue and requires user interaction where an automated solution has been working reliably for quite some time. Uhm. Knowing the reason for the block lets the package manager solve the problem in the most intelligent available way. Merely being sort-of told the expected resolution does not. You're contradicting yourself there - until now you only mentioned user- visible messages, which now suddenly become hints for the package manager. Don't try to confuse issues like that. Now I do wonder what you can explain about a block - some files collide ? How does that help the package manager decide what to do? What can it do, except unmerging one package or refusing to merge another one? How does that differ from the portage solution to the blocker situation? Automated resolution is not always possible Indeed, in such cases you can let the package manager abort or a good idea. Again a subjective thing. This bacon here, buying that was a good idea. I should give you some, it's totally awesome! Also, having more information available for the user and being able to suggest an automated resolution are not in the least bit contradictory. ... which means that we can let the package manager handle all the obvious cases and try to give the user more information in the rare cases where it cannot find a valid solution on its own. Cool. * be based around tree requirements, not some side effects of some code someone happened to write without considering the implications. What is a tree requirement? (Nice buzzword btw) A tree requirement is one that comes about as a result of studying what ebuilds do now and what they'd like to do in the future, rather than one that comes around based upon what someone happens to code. I am confused. I did not think that ebuilds have desires, so I have no idea what they'd like to do in the future. And it does in no way tell me what a tree requirement is (unless you mean happy photons, which are emitted by free- range ebuilds when you try to source them in the kitchen) Incidentally most of our ebuilds are based upon what someone happened to code. Personally I think that many upstream devs didn't have a great plan (or at least they didn't like to express it in the code ;) ) and still we have an ebuild based upon their coding, uhm, accidents. But we adapt to it, and the result is quite impressive. Somewhere a while ago I read a funny idea - the more rules a contract needs the less trust there is. If you trust someone you agree, shake hands, deal complete. Only if there is not enough trust do you need
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Mon, 18 May 2009 22:47:30 +0200 Patrick Lauer patr...@gentoo.org wrote: No, they're temporary except when things go wrong, at which point there's no indication that they'll be fixed. When things go wrong they go wrong. Indeed. When things go wrong, they go wrong beyond the scope of the failure in question. Which either means that the deps are wrong/incomplete or that portage has algorithmic flaws which should be corrected. I'd expect you to at least point to the relevant bugs and not just state some emotional mumbo-jumbo. Look at the new slot deps in EAPI 3. So the deps were not precise enough, and now we improve that. Which means that portage will only get more precise in the future. Awesome! ...and until they're in wide use, Portage's assumptions are dangerous. No, broke. What he did was in direct violation of PMS and in direct violation of assumptions made by many packages. So PMS did once again not reflect reality, and there were some buggy packages. Uhm. No. PMS reflected how Portage used to work, and packages relied upon how Portage used to work. Maybe we should spend more time on making PMS a standard that documents current and past behavior instead of omitting things (mtime, bash 3.1) or keeping it ambiguous so that two implementations can be compliant while delivering incompatible results? Uhm. PMS correctly reflects current and past behaviour on those issues. * work by explaining the reason for the blocker, rather than sort-of stating the expected resolution. That's dumb ;) (Sorry, emotional statement) I mean, it does not help to solve the issue and requires user interaction where an automated solution has been working reliably for quite some time. Uhm. Knowing the reason for the block lets the package manager solve the problem in the most intelligent available way. Merely being sort-of told the expected resolution does not. You're contradicting yourself there - until now you only mentioned user- visible messages, which now suddenly become hints for the package manager. Re-read what I said, alongside the original discussion on replacing blockers. Explaining is not exclusively limited to the user. Now I do wonder what you can explain about a block - some files collide ? How does that help the package manager decide what to do? What can it do, except unmerging one package or refusing to merge another one? How does that differ from the portage solution to the blocker situation? Yes, that's one explanation you'd give to the package manager. As you'll recall from your reading of the previous discussion, there are four different ways in which blockers are commonly used, and the best response from the package manager to each situation is different. A tree requirement is one that comes about as a result of studying what ebuilds do now and what they'd like to do in the future, rather than one that comes around based upon what someone happens to code. I am confused. I did not think that ebuilds have desires, so I have no idea what they'd like to do in the future. And it does in no way tell me what a tree requirement is (unless you mean happy photons, which are emitted by free- range ebuilds when you try to source them in the kitchen) Then I suggest you take some basic English classes. Incidentally most of our ebuilds are based upon what someone happened to code. But the ebuild design (or at least the clean parts of it...) is not. ...except for the things that it broke, which necessitated shoving !! blocks in at the last minute. And I'll remind you that there were discussions about a proper blocker solution before Zac went and did his thing, bikeshedding and circular reasoning in large amounts, stalling any progress for a long time ... until someone provided a working implementation that solved a large enough amount of issues to gain the support of the majority of devs (and big cheers from so many users!). Funnily enough, the original discussion was extremely productive and didn't involve any of the nonsense you're coming up with now. (If it had been as bad as you suggest council would have banninated it within the shortest amount of time...) That was back in the bad old days before the Council agreed to step in when Portage did that kind of thing. In fact, the blocker changes were one of the things that lead to the Council saying in future, we'll package.mask Portage if it does that kind of behaviour change again. and the overwhelming view a minority view, but let's not get distracted by such subjective matters. Please point me to people involved in the discussion who did not agree with the views presented. Provide a list of message IDs to support your claim. -- Ciaran McCreesh signature.asc Description: PGP signature
