[gentoo-dev] RFC: qt.eclass

[gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

(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 though it's not compatible.  Enter my 
proposed qt.eclass (which also replaces kde-functions.eclass for people who 
are using it strictly for Qt).

Now you can:

inherit qt

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.

If you don't need anything this fancy (that is, if the ebuild will work with 
any Qt3 version), then the eclass isn't necessary; just change the ebuild to:

DEPEND="x11-libs/qt-3*" 

As an added bonus, you get an exported pkg_setup function which will handle 
some of the same checks that were handled via kde-functions.

Thanks,
Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Donnie Berkholz]

-----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 sounds
like a bad idea.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCxEDRXVaO67S1rtsRAvggAKDQ+Tpj6vywLVTFJ2vHqnLc0GH2jQCg6znN
p3amuxI6r84tb2dNOK5PmBo=
=Qvpf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Mike Frysinger]

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 random functions in DEPEND sounds
> like a bad idea.

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 a variable that changes across ebuilds but retains the same 
value in a specific ebuild (like $PN or $PV), that is OK
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

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 happy.  
It doesn't rely on anything dynamic.

$(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 )

In other words, it's just shorthand for explicitly listing all of the 
versions.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

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 a variable that changes across ebuilds but
> retains the same value in a specific ebuild (like $PN or $PV), that is OK
> -mike

This function doesn't rely on anything that isn't directly within the eclass 
itself - ie, a static list of all of the Qt versions over the ages.  No files 
on the system or environment variables at all.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: qt.eclass

[Michael Sterrett -Mr. Bones.-]

On Thu, 30 Jun 2005, Caleb Tennis wrote:
> 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 happy.
> It doesn't rely on anything dynamic.
>
> $(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 )

Why use a function then?  Why not just supply a variable in the eclass that
is put in the DEPEND?

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Thomas de Grenier de Latour]

On Thu, 30 Jun 2005 14:33:04 -0500
Caleb Tennis <caleb@gentoo.org> 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 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, that's what a small test with CVS
HEAD shows here.)

--
TGL. 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Thursday 30 June 2005 22:37, Michael Sterrett -Mr. Bones.- wrote:
> On Thu, 30 Jun 2005, Caleb Tennis wrote:
> > 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 happy. It doesn't rely on anything dynamic.
> >
> > $(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 )
>
> Why use a function then?  Why not just supply a variable in the eclass that
> is put in the DEPEND?

Because the function takes a parameter - the minimal version required from 
which to start the list in the ||.

Any everyone who thinks functions inside $DEPEND are iffy should look at 
deprange() and deprange-dual()... /me hides

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Thomas de Grenier de Latour]

On Thu, 30 Jun 2005 22:01:42 +0200
Thomas de Grenier de Latour <degrenier@easyconnect.fr> 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 matching version of qt is
already there, then there is no such issue.

--
TGL. 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 02:37 pm, Michael Sterrett -Mr. Bones.- wrote:
> Why use a function then?  Why not just supply a variable in the eclass that
> is put in the DEPEND?

Because you need to be able to specify what the minimum version of Qt you want 
is.  I suppose we could have 50 variables :

QT_MINIMUM_VERSION_3_0_0_RC_3="|| (x11-libs/qt-3.3.4-r5 
x11-libs/qt-3.3.4-r4 ... )"
QT_MINIMUM_VERSION_3_0_0_RC_2=...

DEPEND="$QT_MINIMUM_VERSION_3_0_0_RC_2"

A function seems a bit nicer.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

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, that's what a small test with CVS
> HEAD shows here.)

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 is.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

Dan Armak wrote:	[Thu Jun 30 2005, 04:06:03PM EDT]
> Because the function takes a parameter - the minimal version
> required from which to start the list in the ||.

Makes sense.

> Any everyone who thinks functions inside $DEPEND are iffy should
> look at deprange() and deprange-dual()... /me hides

They're definitely iffy.  Try this at a bash prompt:

    DEPEND="$(exit 1)"

See the problem?  It didn't exit.  That's what will happen if
a function in DEPEND fails: nothing.  Except that yours will currently
stick this in DEPEND:

    !!! error: qt_min_version called with invalid parameter: \"$1\",
    please report bug

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 03:36 pm, Aron Griffis wrote:
> See the problem?  It didn't exit.  That's what will happen if
> a function in DEPEND fails: nothing.  Except that yours will currently
> stick this in DEPEND:
>
>     !!! error: qt_min_version called with invalid parameter: \"$1\",
>     please report bug

No doubt, it's definitely a hack.  However, the only alternative that I can 
see is to rename the package (which I'm not opposed to doing).  That is, 
leave qt3 as "qt" and make qt4 "qt4".

emerge qt4

There's pros and cons to each way me thinks.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Mike Frysinger]

On Thursday 30 June 2005 04:42 pm, Caleb Tennis wrote:
> On Thursday 30 June 2005 03:36 pm, Aron Griffis wrote:
> > See the problem?  It didn't exit.  That's what will happen if
> > a function in DEPEND fails: nothing.  Except that yours will currently
> > stick this in DEPEND:
> >
> >     !!! error: qt_min_version called with invalid parameter: \"$1\",
> >     please report bug
>
> No doubt, it's definitely a hack.  However, the only alternative that I can
> see is to rename the package (which I'm not opposed to doing).  That is,
> leave qt3 as "qt" and make qt4 "qt4".

i'd prefer to not split QT into sep packages
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Thursday 30 June 2005 23:36, Aron Griffis wrote:
> Dan Armak wrote:	[Thu Jun 30 2005, 04:06:03PM EDT]
>
> > Because the function takes a parameter - the minimal version
> > required from which to start the list in the ||.
>
> Makes sense.
>
> > Any everyone who thinks functions inside $DEPEND are iffy should
> > look at deprange() and deprange-dual()... /me hides
>
> They're definitely iffy.  Try this at a bash prompt:
>
>     DEPEND="$(exit 1)"
>
> See the problem?  It didn't exit.  That's what will happen if
> a function in DEPEND fails: nothing.  Except that yours will currently
> stick this in DEPEND:
>
>     !!! error: qt_min_version called with invalid parameter: \"$1\",
>     please report bug
>
Instead of 'exit 1', qt_min_version should use die. I use that in deprange and 
it does work inside $DEPEND.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Olivier Crete]

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, you should rather sort them in
> > decreasing order. (At least, that's what a small test with CVS
> > HEAD shows here.)
> 
> 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.3 since qt3 probably wont have any new major
release ?


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 7309 bytes --]

Dan Armak wrote:	[Thu Jun 30 2005, 05:11:10PM EDT]
> Instead of 'exit 1', qt_min_version should use die. I use that in
> deprange and it does work inside $DEPEND.

Well, it's more visible, but it doesn't stop the emerge.  I just put
DEPEND="$(die)" into an ebuild to test.  Here is what happens.  It
also gives you an idea of why putting functions into DEPEND is bad:
they get evaluated A LOT.  (jump down for more message content)

----------------------------------------------------------------------

$ sudo emerge keychain

Performing Global Updates: /opt/agriffis/portage/profiles/updates/3Q-2004
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
..................................................................................................................................................................................................
Calculating dependencies  
!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.
                                                                                                  ...done!
>>> emerge (1 of 1) net-misc/keychain-2.5.4.1 to /

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> md5 src_uri ;-) keychain-2.5.4.1.tar.bz2

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> Unpacking source...
>>> Unpacking keychain-2.5.4.1.tar.bz2 to /var/tmp/portage/keychain-2.5.4.1/work
>>> Source unpacked.

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> Test phase [not enabled]: net-misc/keychain-2.5.4.1

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


>>> Install keychain-2.5.4.1 into /var/tmp/portage/keychain-2.5.4.1/image/ category net-misc
man:
prepallstrip:
strip: ia64-unknown-linux-gnu-strip --strip-unneeded
strip: ia64-unknown-linux-gnu-strip --strip-unneeded
>>> Completed installing keychain-2.5.4.1 into /var/tmp/portage/keychain-2.5.4.1/image/

>>> Merging net-misc/keychain-2.5.4.1 to /

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

--- /usr/
--- /usr/bin/
>>> /usr/bin/keychain
--- /usr/share/
--- /usr/share/doc/
--- /usr/share/doc/keychain-2.5.4.1/
>>> /usr/share/doc/keychain-2.5.4.1/README.gz
>>> /usr/share/doc/keychain-2.5.4.1/ChangeLog.gz
>>> /usr/share/doc/keychain-2.5.4.1/keychain.pod.gz
--- /usr/share/man/
--- /usr/share/man/man1/
>>> /usr/share/man/man1/keychain.1.gz
>>> Safely unmerging already-installed instance...

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

--- !mtime obj /usr/share/man/man1/keychain.1.gz
--- !mtime obj /usr/share/doc/keychain-2.5.4.1/keychain.pod.gz
--- !mtime obj /usr/share/doc/keychain-2.5.4.1/README.gz
--- !mtime obj /usr/share/doc/keychain-2.5.4.1/ChangeLog.gz
--- !mtime obj /usr/bin/keychain
--- !empty dir /usr/share/man/man1
--- !empty dir /usr/share/man
--- !empty dir /usr/share/doc/keychain-2.5.4.1
--- !empty dir /usr/share/doc
--- !empty dir /usr/share
--- !empty dir /usr/bin
--- !empty dir /usr

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> original instance of package unmerged safely.

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


 * Please see the Keychain Guide at
 * http://www.gentoo.org/doc/en/keychain-guide.xml
 * for help getting keychain running

>>> Regenerating /etc/ld.so.cache...
>>> net-misc/keychain-2.5.4.1 merged.

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


>>> clean: No packages selected for removal.

>>> Auto-cleaning packages ...

>>> No outdated packages were found on your system.


 * GNU info directory index is up-to-date.
 * IMPORTANT: 60 config files in /etc need updating.
 * IMPORTANT: 24 config files in /usr/lib/X11/xkb need updating.
 * Type emerge --help config to learn how to update config files.

----------------------------------------------------------------------

For the curious, here is the current list of qt deps in portage:

    $ egrep -hro '[<>=]*x11-libs/qt-[-0-9r.*]+' --include='*.e*' . | sort -u
    =x11-libs/qt-2*
    =x11-libs/qt-3*
    =x11-libs/qt-3.1*
    =x11-libs/qt-3.3*
    >=x11-libs/qt-2.2.0
    >=x11-libs/qt-2.2.4
    >=x11-libs/qt-2.3
    >=x11-libs/qt-2.3.0
    >=x11-libs/qt-3
    >=x11-libs/qt-3.0
    >=x11-libs/qt-3.0.0
    >=x11-libs/qt-3.0.1
    >=x11-libs/qt-3.0.3
    >=x11-libs/qt-3.0.5
    >=x11-libs/qt-3.1
    >=x11-libs/qt-3.1.0
    >=x11-libs/qt-3.1.0-r1
    >=x11-libs/qt-3.1.0-r3
    >=x11-libs/qt-3.1.1
    >=x11-libs/qt-3.1.2
    >=x11-libs/qt-3.1.2-r3
    >=x11-libs/qt-3.2
    >=x11-libs/qt-3.2.0
    >=x11-libs/qt-3.2.1-r2
    >=x11-libs/qt-3.2.3
    >=x11-libs/qt-3.3
    >=x11-libs/qt-3.3.0
    >=x11-libs/qt-3.3.0-r1
    >=x11-libs/qt-3.3.1
    >=x11-libs/qt-3.3.2
    >=x11-libs/qt-3.3.3
    >=x11-libs/qt-3.3.3-r1
    >=x11-libs/qt-3.3.4

I agree with vapier, btw, I'd rather not see qt split into separate
packages just to work around a lack in portage (which I think we all
expect will be fixed eventually).  I'm not completely against using
a function to do what you're doing, but I want to make sure you
understand that it's only superficially better than using a set of
variables in qt.eclass.

Thanks for taking the time to solve this kind of problem and being
willing to discuss it.

Regards,
Aron

P.S. I committed a couple bash syntax and whitespace fixes to
qt.eclass plus changed the error message from echo to die.

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Thomas de Grenier de Latour]

On Thu, 30 Jun 2005 17:38:32 -0400
Aron Griffis <agriffis@gentoo.org> wrote:

> Well, it's more visible, but it doesn't stop the emerge.  I
> just put DEPEND="$(die)" into an ebuild to test.

Something that "works" better (ie., "makes portage stop during
metadata caching") is to put a non-zero return code in the
function in case of error, and then call die from the ebuild: 

 DEPEND="$(qt_min_version 3.3)" \
	|| die "Error in DEPEND"

And sure, the error messages from the function should go to
stderr if you want to see them.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Friday 01 July 2005 00:38, Aron Griffis wrote:
> Dan Armak wrote:	[Thu Jun 30 2005, 05:11:10PM EDT]
>
> > Instead of 'exit 1', qt_min_version should use die. I use that in
> > deprange and it does work inside $DEPEND.
>
> Well, it's more visible, but it doesn't stop the emerge.  I just put
> DEPEND="$(die)" into an ebuild to test.  Here is what happens.  It
> also gives you an idea of why putting functions into DEPEND is bad:
> they get evaluated A LOT.  (jump down for more message content)
I see now that in my case, emerge aborted on die() due to a side effect:
beta kchmviewer # emerge konqueror -pv

These are the packages that I would merge, in order:

Calculating dependencies   waiting for lock 
on /dev/shm/aux_db_key_temp.portage_lockfile

!!! ERROR: kde-base/konqueror-3.4.1 failed.
!!! Function deprange-list, Line 426, Exitcode 0
!!! deprange(): unsupported parameters 1 2 - BASEVER must be identical
!!! If you need support, post the topmost build error, NOT this status 
message.

 -

!!! Problem in kde-base/konqueror dependencies.
!!! too many values to unpack exceptions

...OK, so deprange() needs to signal errors out-of-band. Like setting a 
KM_ERROR variable which causes the eclass to abort later on.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Chris Bainbridge]

On 30/06/05, Olivier Crete <tester@gentoo.org> 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.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?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Thursday 30 June 2005 23:11, Dan Armak wrote:
>
> Instead of 'exit 1', qt_min_version should use die. I use that in
> deprange and it does work inside $DEPEND.

Wouldn't this be a good time to implement actual dependency ranges in 
portage. Btw. I normally use the following hack that portage might 
actually be made to understand:

DEPEND="<x11-libs/qt-4.0 !<x11-libs/qt-3.2.1"

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Thursday 30 June 2005 22:01, Thomas de Grenier de Latour wrote:
> On Thu, 30 Jun 2005 14:33:04 -0500
>
> Caleb Tennis <caleb@gentoo.org> 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 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, that's what a small test with CVS
> HEAD shows here.)

Worst, when none of the candidates is installed, it will install the first 
one.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Friday 01 July 2005 12:15, Paul de Vrieze wrote:
> On Thursday 30 June 2005 23:11, Dan Armak wrote:
> > Instead of 'exit 1', qt_min_version should use die. I use that in
> > deprange and it does work inside $DEPEND.
>
> Wouldn't this be a good time to implement actual dependency ranges in
> portage. 
Wouldn't any time be a good time? :-)

> Btw. I normally use the following hack that portage might 
> actually be made to understand:
>
> DEPEND="<x11-libs/qt-4.0 !<x11-libs/qt-3.2.1"
This depends on the fact that we don't actually have different-slotted 
versions of QT <3.2.1 in portage. If we still had eg qt 2.x, this would block 
it. So it's a temporary hack that'll only work for QT based on the fact that 
all qt 3.x versions have the same slot.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Friday 01 July 2005 11:55, Chris Bainbridge wrote:
> On 30/06/05, Olivier Crete <tester@gentoo.org> 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.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?

Sometimes we need to specify a minimal version or revision because something 
depends on specific fixes made there and needs to force a qt upgrade.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

On Friday 01 July 2005 14:28, Dan Armak wrote:
> On Friday 01 July 2005 12:15, Paul de Vrieze wrote:
> > On Thursday 30 June 2005 23:11, Dan Armak wrote:
> > > Instead of 'exit 1', qt_min_version should use die. I use that in
> > > deprange and it does work inside $DEPEND.
> >
> > Wouldn't this be a good time to implement actual dependency ranges in
> > portage.
>
> Wouldn't any time be a good time? :-)
>
> > Btw. I normally use the following hack that portage might
> > actually be made to understand:
> >
> > DEPEND="<x11-libs/qt-4.0 !<x11-libs/qt-3.2.1"
>
> This depends on the fact that we don't actually have different-slotted
> versions of QT <3.2.1 in portage. If we still had eg qt 2.x, this would
> block it. So it's a temporary hack that'll only work for QT based on
> the fact that all qt 3.x versions have the same slot.

I agree. What would be necessary is next to the "||" operator an "&&" 
operator that would select a single package that has both conditions, but 
that does not restrict what is installed.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

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

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.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Francesco R]

Paul de Vrieze wrote:

>On Thursday 30 June 2005 23:11, Dan Armak wrote:
>  
>
>>Instead of 'exit 1', qt_min_version should use die. I use that in
>>deprange and it does work inside $DEPEND.
>>    
>>
>
>Wouldn't this be a good time to implement actual dependency ranges in 
>portage. Btw. I normally use the following hack that portage might 
>actually be made to understand:
>
>DEPEND="<x11-libs/qt-4.0 !<x11-libs/qt-3.2.1"
>
>Paul
>
>  
>
Hum ranges ? This remember me something ... ahh yes I've written a pair
of function to apply patches only for ranges of versions, pure bash
inheriting versionator.eclass .

Here they are:

# this function use "version_compare" to check if a version number
# fall inside a range.
# the range may include or not the extremes, a square bracket mean
# that the extreme is included, a round one mean that the extreme
# fall outside the range.
# examples:
# with $PVR=3 these ones evaluates as _true_:
# [2,4] [3,4] [2,3] [,4] [2,]
# (2,4)
# (,4) (2,) [3,3] [3,4) (2,3]
# with $PVR=3 these ones evaluates as _false_:
# [8,9]
# (3,4) (2,3) (8,9)
# (3,3)
check_version_range() {
  local range_s="${1}"
  local have_s="${2:-${PVR}}"
  [[ -z "$range_s" ]] && return 1
  local bound kind vc

  bound=${range_s%%,*}
  bound=${bound:1}
  bound=${bound:-0}
  local kind=${range_s:0:1}
  case "$kind" in
    '[') kind=2;;
    '(') kind=1;;
    *)  die "check_version_range left kind error: \"${range_s}\""
      return 50;;
  esac
  version_compare "${bound}" "${have_s}"
  [[ $? -gt $kind ]] && return 2

  local bound=${range_s##*,}
  bound=${bound:0:$(( ${#bound} -1 ))}
  bound=${bound:-99999}
  local kind=${range_s:$(( ${#range_s} -1 ))}
  case "$kind" in
    ']') kind=2;;
    ')') kind=3;;
    *)  die "check_version_range right kind error: \"${range_s}\""
      return 50;;
  esac
  #'
  version_compare "${bound}" "${have_s}"
  vt=$?
  [[ $vt -lt $kind ]] && return 3

  return 0
}


# Find all the applicable patch files in a directory and move them in
# EPATCH_SOURCE (yes EPATCH_SOURCE here is a /destination/)
# two optional arguments are accepted:
# 1) directory where find the candidate patches (default to $FILESDIR)
# 2) version on which check applicable patches (default to $PVR)
# the file examined must have one or more line starting with the string
# "###MY_VER_RANGE" and followed from one or two version numbers (VN).
# For every of the so formatted lines the function will check if our
# version is greatest or equal to the first VN and less than the second
# VN (defaulted to infinite if empty)
# example:
###MY_VER_RANGE 4.0 4.0.16
###MY_VER_RANGE 4.1 4.1.4
###MY_VER_RANGE 5.0
# if a patch contains these three lines then:
# all version >= 4.0 but < 4.0.16,
# all version >= 4.1 but < 4.0.16,
# all version >= 5.0 will be affected by this patch
#
# bug uses version_compare declared experimental
# <vivo@g.o> (2005-05-18)
copy_applicable_patches() {
  local filesdir="${1:-${FILESDIR}}"
  local have_s="${2:-${PVR}}"

  [[ -d "${EPATCH_SOURCE}" ]] || die "\$EPATCH_SOURCE must be a directory"
  [[ -d "${filesdir}" ]] || die 'sourcedir must be a directory'

  local filecandidates=""
  filecandidates="$( ls ${filesdir}/*.${EPATCH_SUFFIX} 2>/dev/null )"
  if [[ -z $filecandidates ]] ; then
    einfo "No candidate patches found (lucky version?)"
    return 0
  fi

  local ver_ranges use_flags
  local has_ver=1 has_use=1
  local apply=1
  local filelist=""

  for x in ${filecandidates} ; do

    # Gater data
    ver_ranges=$( head -n50 "${x}" | sed '/^###MY_VER_RANGE/'\!'d; s///;q' )
    use_flags=$( head -n50 "${x}" | sed '/^###MY_USE_FLAG/'\!'d; s///;q' )

    if [[ -n "${ver_ranges}" || -n "${use_flags}" ]] ; then
      if [[ -z "${ver_ranges}" ]] ; then
        has_ver=0
      else
        has_ver=1
        for y in ${ver_ranges} ; do
          if check_version_range "${y}" "${have_s}" ; then
            has_ver=0
            continue
          fi
        done
      fi

      if [[ -z "${use_flags}" ]] ; then
        has_use=0
      else
        has_use=1
        for y in ${use_flags} ; do
          if [[ "${y:0:1}" == "-" ]] ; then
            if ! useq "${y:1}" ; then
              has_use=0
              continue
            fi
          else
            if useq "${y}" ; then
              has_use=0
              continue
            fi
          fi
        done
      fi

      if [[ $has_ver -eq 0 && $has_use -eq 0 ]] ; then
        filelist="${filelist} ${x}"
        einfo "adding   $(basename ${x}) ${ver_ranges} ${use_flags}"
      else
        einfo "skipping $(basename ${x}) ${ver_ranges} ${use_flags}"
      fi

    fi
  done
  filelist="${filelist:1}"
  [[ -n "$filelist" ]] && cp $filelist "${EPATCH_SOURCE}"
}

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Francesco R]

Francesco R wrote:
[snip]
s/

># example:
>###MY_VER_RANGE 4.0 4.0.16
>###MY_VER_RANGE 4.1 4.1.4
>###MY_VER_RANGE 5.0
># if a patch contains these three lines then:
># all version >= 4.0 but < 4.0.16,
># all version >= 4.1 but < 4.0.16,
># all version >= 5.0 will be affected by this patch
>  
>
/
example:
###MY_VER_RANGE  [4.0,4.0.16) [4.1,4.1.4) [5.0,]
# if a patch contains the previous line then:
# all version >= 4.0 but < 4.0.16,
# all version >= 4.1 but < 4.0.16,
# all version >= 5.0 will be affected by this patch
/

[snip]


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Dan Armak wrote:	[Fri Jul 01 2005, 03:42:22AM EDT]
> ...OK, so deprange() needs to signal errors out-of-band. Like setting a 
> KM_ERROR variable which causes the eclass to abort later on.

Heh, doesn't work for the same reason you can't exit.  It's
a subshell.

How about this?

ebuild:
    DEPEND="some stuff"
    qt_min_dep "3.3"

eclass:
    qt_min_dep() {
        if cool; then
            DEPEND="${DEPEND} new stuff"
        else
            die "..."
        fi
    }

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

On Friday 01 July 2005 16:56, Aron Griffis wrote:
> Dan Armak wrote:	[Fri Jul 01 2005, 03:42:22AM EDT]
>
> > ...OK, so deprange() needs to signal errors out-of-band. Like setting a
> > KM_ERROR variable which causes the eclass to abort later on.
>
> Heh, doesn't work for the same reason you can't exit.  It's
> a subshell.
>
> How about this?
>
> ebuild:
>     DEPEND="some stuff"
>     qt_min_dep "3.3"
>
> eclass:
>     qt_min_dep() {
>         if cool; then
>             DEPEND="${DEPEND} new stuff"
>         else
>             die "..."
>         fi
>     }
>
Would work, but be against the general move to make the general ebuild section 
purely declarative :-( I don't want to change a great deal of code merely to 
catch incorrectly written ebuilds, when we can already print messages on 
stderr.

I'd rather signal failure to code outside the subshell by touching a file in 
$T.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Caleb Tennis]

On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
> How about this?
>
> ebuild:
>     DEPEND="some stuff"
>     qt_min_dep "3.3"

How do you handle the ebuilds which use the qt use flag to determine whether 
or not that qt is a dependency?

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Thomas de Grenier de Latour]

On Fri, 1 Jul 2005 17:45:57 +0300
Dan Armak <danarmak@gentoo.org> wrote:

> 
> I'd rather signal failure to code outside the subshell by
> touching a file in $T.
> 

The ${T} directory does not exists when portage source an ebuild
to get its metadatas, so I'm not sure that's a good idea.

Btw, what's wrong with the `DEPEND="$(your_function)" || die`
i've proposed?  Using a return code seems to be the simplest way
to signal a failure, no?

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Jonathan Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas de Grenier de Latour wrote:
 > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> i've proposed?  Using a return code seems to be the simplest way
> to signal a failure, no?
> 

calling a function in a global scope is a bad idea. it leads to lots of
unneccessary (and timely) computations

remember your ebuild/end-of-mentoring quiz?

- --

smithj

Gentoo Developer
[ desktop-misc && netmon &&  documentation ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCxV3Ml5AvwDPiUowRAhosAJ9IWOLs3Eknu3BB/NwkKyAGpx/W3gCfag0P
dbjvgc97tDcrjHE5WSfLtiY=
=XX8N
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Friday 01 July 2005 18:14, Jonathan Smith wrote:
> - gpg control packet
>
> Thomas de Grenier de Latour wrote:
>  > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> >
> > i've proposed?  Using a return code seems to be the simplest way
> > to signal a failure, no?
>
> calling a function in a global scope is a bad idea. it leads to lots of
> unneccessary (and timely) computations
Necessary in the case of kde split ebuilds. Take a look at 
kde-functions.eclass::deprange(). 

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Friday 01 July 2005 18:03, Thomas de Grenier de Latour wrote:
> On Fri, 1 Jul 2005 17:45:57 +0300
>
> Dan Armak <danarmak@gentoo.org> wrote:
> > I'd rather signal failure to code outside the subshell by
> > touching a file in $T.
>
> The ${T} directory does not exists when portage source an ebuild
> to get its metadatas, so I'm not sure that's a good idea.
>
> Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> i've proposed?  Using a return code seems to be the simplest way
> to signal a failure, no?
Sorry, I missed it the first time... Looks like a good way, yes (haven't 
tested).

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Alec Joseph Warner]

Caleb Tennis wrote:
<snip>
> 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.

   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.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

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 change deps from >=qt-3.0 to =qt-3.3 then nobody will be able to work 
with a Qt dependant package until they upgrade Qt.  In the same regard, there 
are people still using Apache1 whom we aren't forcing to upgrade to Apache2 
just so they can use some of the apache modules.

Also, another downside to the =qt-3.3 approach is that it doesn't cleanly 
handle the cases of ">=qt-3.3.2-r1".
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Friday 01 July 2005 17:14, Jonathan Smith wrote:
> Thomas de Grenier de Latour wrote:
>  > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> >
> > i've proposed?  Using a return code seems to be the simplest way
> > to signal a failure, no?
>
> calling a function in a global scope is a bad idea. it leads to lots of
> unneccessary (and timely) computations

It also makes any attempts to parse ebuilds without using bash (our current 
strategy) a lot harder (actually causing bash reimplementation)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

On Friday 01 July 2005 23:19, Paul de Vrieze wrote:
> On Friday 01 July 2005 17:14, Jonathan Smith wrote:
> > Thomas de Grenier de Latour wrote:
> >  > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> > >
> > > i've proposed?  Using a return code seems to be the simplest way
> > > to signal a failure, no?
> >
> > calling a function in a global scope is a bad idea. it leads to lots of
> > unneccessary (and timely) computations
>
> It also makes any attempts to parse ebuilds without using bash (our current
> strategy) a lot harder (actually causing bash reimplementation)
You mean you're actually doing that for portage-cvs? I didn't know that. Does 
'our current strategy' refer to using bash or to not using it?

Anyway, as far as portage goes, if we had version range deps support we 
wouldn't need functions in $DEPEND.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Dan Armak wrote:[Fri Jul 01 2005, 10:45:57AM EDT]
> Would work, but be against the general move to make the general ebuild section 
> purely declarative :-(

Ok, but DEPEND="$(some-function)" is no more declarative.  The
function is evaluated at the time that the ebuild is read, not later
when DEPEND is processed.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

Caleb Tennis wrote:[Fri Jul 01 2005, 10:48:38AM EDT]
> On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
> > How about this?
> >
> > ebuild:
> >     DEPEND="some stuff"
> >     qt_min_dep "3.3"
> 
> How do you handle the ebuilds which use the qt use flag to determine whether 
> or not that qt is a dependency?

Bah, good point.  I knew it was too easy.  :-)

It seems like at this point there is one good suggestion on the table
for an immediate fix: DEPEND="..." || die

Of course we all want more flexible DEPEND processing in portage, but
another avenue of research for somebody is to read the ebuilds (not
necessarily execute the functions) with "set -e".  That doesn't solve
the problem quickly enough for you, since it requires a portage
change, but it would solve the general problem of calling functions
from strings (so long as you only call one!)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Sat, 2 Jul 2005 00:00:38 +0300
Dan Armak <danarmak@gentoo.org> wrote:

> On Friday 01 July 2005 23:19, Paul de Vrieze wrote:
> > It also makes any attempts to parse ebuilds without using bash (our
> > current strategy) a lot harder (actually causing bash
> > reimplementation)
> You mean you're actually doing that for portage-cvs? I didn't know
> that. Does 'our current strategy' refer to using bash or to not using
> it?

He doesn't. Portage-cvs (=2.1) still uses bash and there are no plans
to change that for the ebuild format. However we
_might_ add support for alternate package formats in the future.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[foser]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote:
> > calling a function in a global scope is a bad idea. it leads to lots of
> > unneccessary (and timely) computations
> Necessary in the case of kde split ebuilds. Take a look at 
> kde-functions.eclass::deprange(). 

So you create functions to do things portage really should do ? Wouldn't
pushing the portage team to finally implement a major feature like
depranges be a better idea ?

The gnome team has been dealing with these things forever, but we have a
preference for a global solution instead of inventing our own wheel.

- foser

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[foser]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Fri, 2005-07-01 at 11:15 +0200, Paul de Vrieze wrote:
> Wouldn't this be a good time to implement actual dependency ranges in 
> portage. Btw. I normally use the following hack that portage might 
> actually be made to understand:
> 
> DEPEND="<x11-libs/qt-4.0 !<x11-libs/qt-3.2.1"

This sort of trickery doesn't work in a SLOT-ed environment where
there's a version qt-2 around. The bottomline is that portage needs this
fixed.

- foser

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Saturday 02 July 2005 14:43, foser wrote:
> On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote:
> > > calling a function in a global scope is a bad idea. it leads to lots of
> > > unneccessary (and timely) computations
> >
> > Necessary in the case of kde split ebuilds. Take a look at
> > kde-functions.eclass::deprange().
>
> So you create functions to do things portage really should do ? Wouldn't
> pushing the portage team to finally implement a major feature like
> depranges be a better idea ?
They said a major feature like dep version ranges would never be in a stable 
portage 2.0.x, so I wrote deprange() as a temporary stop-gap measure because 
there was no other feasible way to write the split kde ebuilds. The request 
is in bug 33545.

Maybe I didn't push them enough :-/

>
> The gnome team has been dealing with these things forever, but we have a
> preference for a global solution instead of inventing our own wheel.
I've a preference for that too, I just wasn't up to writing a patch for 
portage at the time. Maybe I should try to do that now, depending on their 
answer to my new comment in 33545...

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Thomas de Grenier de Latour]

On Sat, 2 Jul 2005 15:52:55 +0300
Dan Armak <danarmak@gentoo.org> wrote:

> Maybe I should try to do that now, depending on their answer to
> my new comment in 33545... 

You may also want to have a look on bug #4315, since version
range is no more than a particular case of AND dependency.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Gregorio Guidi]

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:
>
> DEPEND=">=x11-libs/qt-3.2"
>
> Because Qt4 satisfies this depend even though it's not compatible.  Enter
> my proposed qt.eclass (which also replaces kde-functions.eclass for people
> who are using it strictly for Qt).
>
> Now you can:
>
> inherit qt
>
> 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.
>
> If you don't need anything this fancy (that is, if the ebuild will work
> with any Qt3 version), then the eclass isn't necessary; just change the
> ebuild to:
>
> DEPEND="x11-libs/qt-3*"
>
> As an added bonus, you get an exported pkg_setup function which will handle
> some of the same checks that were handled via kde-functions.
>
> Thanks,
> Caleb

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, 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 true for the kde eclasses, but still applies to Qt.
In fact, we need to introduce a new clean eclass for KDE4-based applications, 
so starting from scratch with a kde4.eclass and a qt4.eclass makes a lot of 
sense.

As many already pointed out, using something like
	DEPEND="$(qt_min_version 3.1)"
is very ugly, so we should use it only if it is really unavoidable.

There is also another consideration to do: many Qt applications, or 
applications with optional Qt support, are not maintained by the qt/kde herd.
We had many problems in the past because it was not easy at all to write 
ebuilds for these applications, this time we should make this task as 
intuitive as possible.

There was a lot of discussion internally already with particular focus on the 
kde eclasses, but the problems for Qt and KDE applications are nearly the 
same so designing a new qt eclass uncovers the same problems.

Among the options discussed, I particularly like the following one (I think 
something like this also showed up in this thread, too):

An application based on Qt4 should look just like this:

	inherit qt4

	HOMEPAGE=...
	SRC_URI=...
	...

the qt4 eclass would automatically add a DEPEND="=x11-libs/qt-4*", and would 
provide default src_compile(), src_install()...

For the applciations (<5% ?) that require an higher version of Qt, the ebuild 
should look like:

	NEED_QT="4.1"
	inherit qt4

	HOMEPAGE=...
	SRC_URI=...
	...

the qt4 eclass would insert the right line in DEPEND.

For applications with optional Qt support, the ebuild could manually set the 
dependency on x11-libs/qt; it is enough to ship a qt4-info.eclass that  
provides useful functions, with qt_min_versions() among them.

So an ebuild with optional Qt support could be like

	inherit qt4-info

	HOMEPAGE=...
	SRC_URI=...

	DEPEND="qt? ( =x11-libs/qt-4* )"
	...

(I think this would be the case for 99% of the ebuilds) or

	inherit qt4-info

	HOMEPAGE=...
	SRC_URI=...

	DEPEND="qt? ( $(qt_min_version 4.1.2) )"
	...

if there's absolutely no other way to do it.

This proposal is meant for Qt, but it should be read as a proposal for both Qt 
and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in the 
same way.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

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 true for the kde eclasses, but still applies to Qt.
> In fact, we need to introduce a new clean eclass for KDE4-based
> applications, so starting from scratch with a kde4.eclass and a qt4.eclass
> makes a lot of sense.
[...]
> An application based on Qt4 should look just like this:
>
> 	inherit qt4
>
> 	HOMEPAGE=...
> 	SRC_URI=...
> 	...
[...]
> This proposal is meant for Qt, but it should be read as a proposal for both
> Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in
> the same way.

I know you know this, but for other readers, this is exactly the design of the 
current kde.eclass+kde-functions.eclass :-) At least it was until they 
gathered up a huge amount of special cases and backward support. Today a 
typical kde ebuild still looks as simple as that, but sometimes you need to 
know how to work around some sensitive points (like the recent bug where the 
eclass fails to disable the broken visibility support...), and for kde-base 
you also need to know deprange() and some other tricks.

Although the notation PATCHES="$FILESDIR/foo.diff" didn't catch on well enough 
for some reason. Other than me, most people seem to prefer to override 
src_unpack just to call epatch...

So if we ever get a chance to cleanup the existing kde3 eclasses they'll look 
just like that, and might even share some code with the new kde4 eclasses 
(which should be separate due to kde4's completely new build system). (Mmm 
GLEP 33...)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Gregorio Guidi]

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 Qt, but it should be read as a proposal for
> > both Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that
> > work in the same way.
>
> I know you know this, but for other readers, this is exactly the design of
> the current kde.eclass+kde-functions.eclass :-) At least it was until they
> gathered up a huge amount of special cases and backward support.

Exactly, in fact this should be reassumed also as "kde eclass started from 
scratch, without the evil need-kde()" :)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

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, 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 true for the kde eclasses, but still applies to Qt.
> In fact, we need to introduce a new clean eclass for KDE4-based
> applications, so starting from scratch with a kde4.eclass and a qt4.eclass
> makes a lot of sense.

I completely agree.

> As many already pointed out, using something like
> 	DEPEND="$(qt_min_version 3.1)"
> is very ugly, so we should use it only if it is really unavoidable.

I agree too, but I haven't seen yet how it can be avoided.

> An application based on Qt4 should look just like this:
>
> 	inherit qt4
>
> 	HOMEPAGE=...
> 	SRC_URI=...
> 	...
>
> the qt4 eclass would automatically add a DEPEND="=x11-libs/qt-4*", and
> would provide default src_compile(), src_install()...

That's fine, except I would think that very few ebuilds would be able to make 
use of a default src_compile() and src_install().  It works for the kde 
eclass because most of the kde packages are built using the standard kde 
auto* scripts, but I doubt many qt only packages have the same build 
structure.

[snip]

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 
&& deps, I fear there's no real way around it.  I don't think we'll have time 
to wait much longer; I expect ebuilds that need qt4 will start appearing in 
portage soon and the minute that qt4 is marked ~arch it instantly creates the 
dependency mess addressed previously.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Friday 01 July 2005 23:00, Dan Armak wrote:
> On Friday 01 July 2005 23:19, Paul de Vrieze wrote:
> > On Friday 01 July 2005 17:14, Jonathan Smith wrote:
> > > Thomas de Grenier de Latour wrote:
> > >  > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> > > >
> > > > i've proposed?  Using a return code seems to be the simplest way
> > > > to signal a failure, no?
> > >
> > > calling a function in a global scope is a bad idea. it leads to lots of
> > > unneccessary (and timely) computations
> >
> > It also makes any attempts to parse ebuilds without using bash (our
> > current strategy) a lot harder (actually causing bash reimplementation)
>
> You mean you're actually doing that for portage-cvs? I didn't know that.
> Does 'our current strategy' refer to using bash or to not using it?

I'm not working on portage. I don't know what people do, but parsing ebuilds 
is certainly easier orders of magnitude faster than bash parsing them (I have 
prove of concept code).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: RFC: qt.eclass

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Sat, Jul 02, 2005 at 01:43:43PM +0200, foser wrote:
> On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote:
> > > calling a function in a global scope is a bad idea. it leads to lots of
> > > unneccessary (and timely) computations
> > Necessary in the case of kde split ebuilds. Take a look at 
> > kde-functions.eclass::deprange(). 
> 
> So you create functions to do things portage really should do ? Wouldn't
> pushing the portage team to finally implement a major feature like
> depranges be a better idea ?
> 
> The gnome team has been dealing with these things forever, but we have a
> preference for a global solution instead of inventing our own wheel.

*cough*
chip in.

Kind of tired of hearing of "portage devs ain't doing anything", we 
_are_ actually attempting improvements, but people seem to be missing 
a somewhat obvious fact about development of portage.

Consider this; if it were easy to implement, one might suspect it 
would have been implemented already.  Nature of the portage code is that the 
stuff people want (I'm talking about mainly dep syntax expansion, remote 
crap etc, not tweaks to emerge output) is no longer low hanging fruit, 
nor has it been for quite sometime.  Core problems in the code 
(design mainally) limit easily pulling off these features that those 
who don't look in the code think should be a one hour extension.

Work is underway to try and fix things so that all of the stuff 
people have been poking about over the years is low hanging (whether 
implemented already, or easy to extend and pull off).  If you want 
this stuff, know python or are willing to independantly bootstrap your 
python capabilities on an actual project, chip in, or pretty much sit 
back.

Bit harsh, but help is needed, not bitching, nor further broken 
kludges slipped into the tree/portage source instead of trying to fix 
the actual underlying, _harder_ and further reaching problems.

Y'all know FOSS, stuff gets implemented by those with either an explicit 
interest in a feature, or interest in the general improvement of a project- 
further effort invested is limited by the amount of time developers 
can realistically contribute.

So... chip in.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: qt.eclass

[Gregorio Guidi]

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 && deps, I fear there's no real way around it.  I don't
> think we'll have time to wait much longer; I expect ebuilds that need qt4
> will start appearing in portage soon and the minute that qt4 is marked
> ~arch it instantly creates the dependency mess addressed previously.

We can start porting those ebuilds that just need to be changed using 
"=x11-libs/qt-3*". Then we can change kde-functions.eclass for the ebuilds 
using need-qt() (which can set something like e.g. || ( =x11-libs/qt-3.3* ... 
=x11-libs/qt-3.1* ) ); and finally we can deal with the remaining ebuilds 
(not many probably) using the qt.eclass (or qt3.eclass, or qt3-info.eclass, 
or whatever), or again something like "|| ( =x11-libs/qt-3.3* ... 
=x11-libs/qt-3.1* ) )" where possible.
-- 
gentoo-dev@gentoo.org mailing list