Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpfZwDGAJ10B.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Sat, 2 Jul 2005 00:00:38 +0300 Dan Armak [EMAIL PROTECTED] 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. pgpRElbs2fscL.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpZleaWmRJ97.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpZBr8b9F0Yz.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpTRjWP1GFKs.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGK1foe2FfS.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpbLY3fAf31a.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp4FUa4wgiZm.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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
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
pgpuioGFDf2I3.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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
On Fri, 1 Jul 2005 17:45:57 +0300
Dan Armak [EMAIL PROTECTED] 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
-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
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 pgpY4Deq30kXt.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Friday 01 July 2005 18:03, Thomas de Grenier de Latour wrote:
On Fri, 1 Jul 2005 17:45:57 +0300
Dan Armak [EMAIL PROTECTED] 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
pgpw9chQK33m1.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpUtMdsW3iQp.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpYA48zJK20i.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgplQXYUI4PWe.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpOnRcudN3AM.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgp057Yns1Gpi.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 pgpExPqVfjVEn.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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
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
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 pgpFR8CXBg7se.pgp Description: PGP signature
