On Saturday 02 July 2005 22:54, Caleb Tennis wrote:
> While your proposal works okay for the qt4 scenario, I'm more concerned
> with the existing qt3 at the moment. As is, I stil l don't see a way
> around what has been proposed for those ebuilds. Until portage has the
> ability to handle && de
On Saturday 02 July 2005 14:41, Gregorio Guidi wrote:
> I'm back from a trip and I'm slowly catching up with all the mails on this
> topic, but a couple of things come to my mind ... please bear with me.
>
> First, a new eclass for Qt4 ebuilds should really be called qt4.eclass,
> with another one,
On Saturday 02 July 2005 22:09, Dan Armak wrote:
> On Saturday 02 July 2005 22:41, Gregorio Guidi wrote:
> [...]
>
> > An application based on Qt4 should look just like this:
> >
> > inherit qt4
> >
> > HOMEPAGE=...
> > SRC_URI=...
> > ...
>
> [...]
>
> > This proposal is meant for
On Saturday 02 July 2005 22:41, Gregorio Guidi wrote:
> First, a new eclass for Qt4 ebuilds should really be called qt4.eclass,
> with another one, qt3.eclass, to be used to port the current Qt3-based
> ebuilds. Dealing with more than one major version in a single eclass is a
> pain; this is mostly
On Thursday 30 June 2005 19:54, Caleb Tennis wrote:
> (I'd like to hear your thoughts and comments on the matter below before I
> start the process of changing ebuilds to comply.)
>
> With Qt4 entering portage, we are going to start running into a dependency
> problem with ebuilds that do:
>
> DEPE
On Friday 01 July 2005 10:35 am, Alec Joseph Warner wrote:
>You don't force anyone to do anything. If they don't want to upgrade
> because they can't then they can p.mask the programs they can't upgrade.
But this isn't about upgrading Qt, it's about the packages that depend on it.
If you ch
Caleb Tennis wrote:
2. You'll force a user to upgrade to qt 3.3 if they attempt to install any
package that depends on Qt. Speaking from personal experience, I still have
some servers using Qt 3.1 because I have programs running 24/7 that rely on
Qt and simply cannot be upgraded right now.
On Friday 01 July 2005 03:55 am, Chris Bainbridge wrote:
> > Why not just use =qt-3.3 since qt3 probably wont have any new major
> > release ?
>
> This would seem like the easiest option. Is there any reason not to do
> it this way?
Yes, two of them.
1. You don't know that there won't be a 3.4 qt
On Friday 01 July 2005 11:55, Chris Bainbridge wrote:
> On 30/06/05, Olivier Crete <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
> > > I'm sorry, yes, that's what I do in this case.
> > >
> > > Also, the eclass is in portage if anyone is so inclined to see ho
On Thursday 30 June 2005 22:01, Thomas de Grenier de Latour wrote:
> On Thu, 30 Jun 2005 14:33:04 -0500
>
> Caleb Tennis <[EMAIL PROTECTED]> wrote:
> > $(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3
> > =x11-libs/qt-3.3.3-r1 =x11-libs/qt-3.3.3-r2
> > =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )
>
On 30/06/05, Olivier Crete <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
> >
> > I'm sorry, yes, that's what I do in this case.
> >
> > Also, the eclass is in portage if anyone is so inclined to see how harmless
> > it
> > really i
>
> Why not just use =qt-3.
On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
> On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote:
> > It seems that portage evaluates disjonction left to right and
> > stops on the first match it founds. Thus, if you want want it to
> > choose the best matching version,
On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote:
> It seems that portage evaluates disjonction left to right and
> stops on the first match it founds. Thus, if you want want it to
> choose the best matching version, you should rather sort them in
> decreasing order. (At least,
On Thu, 30 Jun 2005 22:01:42 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> It seems that portage evaluates disjonction left to right and
> stops on the first match it founds.
Sure, the above holds only for picking a package to install when
the dep is not already satisfied. If a m
On Thu, 30 Jun 2005 14:33:04 -0500
Caleb Tennis <[EMAIL PROTECTED]> wrote:
>
> $(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3
> =x11-libs/qt-3.3.3-r1 =x11-libs/qt-3.3.3-r2
> =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )
>
It seems that portage evaluates disjonction left to right and
stops on th
On Thursday 30 June 2005 02:15 pm, Mike Frysinger wrote:
> it depends on the information that the function acts upon ...
>
> if the results depend on stuff that is installed (i.e. things in
> /var/db/pkg) or env vars the user manipulates (like $SOME_FOO), then that's
> bad ... if the results depend
On Thursday 30 June 2005 01:58 pm, Donnie Berkholz wrote:
> I'm no expert on portage, but running random functions in DEPEND sounds
> like a bad idea.
Understandable, but I don't know any other way to do it. The function does
nothing more than return a list of ebuild versions to make the depend
On Thursday 30 June 2005 02:58 pm, Donnie Berkholz wrote:
> Caleb Tennis wrote:
> > DEPEND="$(qt_min_version 3.0)"
> > or
> > DEPEND="qt? ( $(qt_min_version 3.1.2-r2) )"
> >
> > And the eclass will expand out all Qt3 ebuilds which satisfy the
> > statement.
>
> I'm no expert on portage, but running
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Caleb Tennis wrote:
> DEPEND="$(qt_min_version 3.0)"
> or
> DEPEND="qt? ( $(qt_min_version 3.1.2-r2) )"
>
> And the eclass will expand out all Qt3 ebuilds which satisfy the statement.
I'm no expert on portage, but running random functions in DEPEND
(I'd like to hear your thoughts and comments on the matter below before I
start the process of changing ebuilds to comply.)
With Qt4 entering portage, we are going to start running into a dependency
problem with ebuilds that do:
DEPEND=">=x11-libs/qt-3.2"
Because Qt4 satisfies this depend even
20 matches
Mail list logo
