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
2009/5/18 Steven J Long :
> David Leverton wrote:
>
>> 2009/5/17 Ben de Groot :
>>> 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 c
On Mon, 18 May 2009 17:42:19 +0200
Robert Buchholz 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 comb
On Monday 18 May 2009, Jeroen Roovers wrote:
> On Mon, 18 May 2009 16:16:46 +0100
>
> Ciaran McCreesh 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 y
On Mon, 18 May 2009 17:28:00 +0200
Jeroen Roovers wrote:
> On Mon, 18 May 2009 16:16:46 +0100
> Ciaran McCreesh 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 sim
Ciaran McCreesh wrote:
> On Mon, 18 May 2009 16:07:20 +0100
> Steven J Long 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?
David Leverton wrote:
> 2009/5/17 Ben de Groot :
>> 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
> generat
On Mon, 18 May 2009 16:16:46 +0100
Ciaran McCreesh 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 sti
On Mon, 18 May 2009 16:07:20 +0100
Steven J Long 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 kil
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
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
On Mon, 18 May 2009 06:59:36 +0200
Ulrich Mueller 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
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
28 matches
Mail list logo
