On Mon, 18 May 2009 22:47:30 +0200
Patrick Lauer 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
q
On Monday 18 May 2009 21:20:10 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 21:08:25 +0200
>
> Patrick Lauer 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
On Mon, 18 May 2009 21:08:25 +0200
Patrick Lauer 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 temp
On Monday 18 May 2009 20:19:24 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 20:05:51 +0200
>
> Maciej Mrozowski 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 tha
On Mon, 18 May 2009 20:05:51 +0200
Maciej Mrozowski 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 "the
On Monday 18 of May 2009 19:26:58 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 19:15:59 +0200
>
> Maciej Mrozowski 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 pac
On Mon, 18 May 2009 19:15:59 +0200
Maciej Mrozowski 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
On Monday 18 of May 2009 16:52:19 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 17:47:52 +0300
[snip]
> 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
On Mon, 18 May 2009 20:01:22 +0300
Alex Alexander 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 pro
On Mon, May 18, 2009 at 19:51, Ciaran McCreesh
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 unrela
On Mon, 18 May 2009 19:42:02 +0300
Alex Alexander wrote:
> > 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?
On Mon, May 18, 2009 at 17:21, Ciaran McCreesh
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 extern
> 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 a
On Mon, 18 May 2009 17:47:52 +0300
Petteri Räty wrote:
> Ciaran McCreesh wrote:
> > On Mon, 18 May 2009 13:04:27 +0300
> > Alex Alexander wrote:
> >> Unfortunately we've got reports from paludis users stating that
> >> they can't update QT from qting-edge anymore.
> >
> > Paludis treats blocks a
Ciaran McCreesh wrote:
> On Mon, 18 May 2009 13:04:27 +0300
> Alex Alexander 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
On Mon, 18 May 2009 13:04:27 +0300
Alex Alexander 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
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 d
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, o
18 matches
Mail list logo
