Re: [gentoo-dev] [RFC] Deprecating an eclass
Doug Klima wrote: Howdy all, We need to agree upon some syntax which we can mark an eclass as deprecated and potentially point to a replacement or multiple replacements. Discuss. Ok. I guess no one else has any feelings about this. Potentially doing something like: DEPRECIATED=$DEPRECATED $ECLASS at the top of each deprecated eclass. In the end $DEPRECATED would have a list of all the eclasses that are deprecated? Maybe even: DEPRECATED_MYECLASS=myreplacement would mean that myeclass.eclass is replaced by myreplacement.eclass ? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Deprecating an eclass
On Mon, 18 Feb 2008 15:43:56 -0500 Doug Klima [EMAIL PROTECTED] wrote: Ok. I guess no one else has any feelings about this. Potentially doing something like: DEPRECIATED=$DEPRECATED $ECLASS Deprecated != depreciated. at the top of each deprecated eclass. In the end $DEPRECATED would have a list of all the eclasses that are deprecated? Maybe even: DEPRECATED_MYECLASS=myreplacement would mean that myeclass.eclass is replaced by myreplacement.eclass ? Well, that depends upon whether you want it to be part of the C/P-V metadata... If you do, it's a cache format change (and you can't easily do DEPRECATED_*). But then, deprecation is a property of the eclass, not an C/P-V. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On 18:20 Mon 18 Feb , Sven Wegener (swegener) wrote:
swegener08/02/18 18:20:47
Modified: flag-o-matic.eclass
Log:
redirect the ewarn message to stderr
Revision ChangesPath
1.122eclass/flag-o-matic.eclass
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.122view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.122content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.121r2=1.122
@@ -614,7 +614,7 @@
# @DESCRIPTION:
# DEPRECATED - Gets the flags needed for NOW binding
bindnow-flags() {
- ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild
+ ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild 2
This seems like something ewarn should do on its own.
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 13:20:52 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: This seems like something ewarn should do on its own. http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.121view=markup http://thread.gmane.org/gmane.linux.gentoo.user/194929 hth, -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-02-17 23h59 UTC
Why can't every week be like this. Remove more packages :) On 2/17/08, Robin H. Johnson [EMAIL PROTECTED] wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-02-17 23h59 UTC. Removals: media-video/usb-pwc-re 2008-02-13 09:48:30 phosphan media-video/usb-pwcx2008-02-13 09:53:09 phosphan net-p2p/eztorrent 2008-02-14 14:42:21 armin76 media-sound/gini2008-02-15 12:51:15 drac media-libs/libmustux2008-02-15 12:53:46 drac net-libs/dclibc 2008-02-15 13:52:26 armin76 media-plugins/streamtuner-live365 2008-02-15 15:09:50 drac media-plugins/streamtuner-local 2008-02-15 15:09:50 drac media-plugins/streamtuner-python2008-02-15 15:09:52 drac media-plugins/streamtuner-xiph 2008-02-15 15:09:53 drac x11-misc/fluxconf 2008-02-15 15:15:54 drac media-libs/libdts 2008-02-15 18:57:31 drac media-libs/hermes 2008-02-15 23:09:02 nyhm x11-themes/gaim-smileys 2008-02-16 19:14:04 tester x11-plugins/autoprofile 2008-02-16 19:23:30 tester x11-plugins/bangexec2008-02-16 19:23:31 tester x11-plugins/gaim-assistant 2008-02-16 19:23:31 tester x11-plugins/gaim-encryption 2008-02-16 19:23:32 tester x11-plugins/gaim-extprefs 2008-02-16 19:23:33 tester x11-plugins/gaim-galago 2008-02-16 19:23:34 tester x11-plugins/gaim-hotkeys2008-02-16 19:23:35 tester x11-plugins/gaim-latex 2008-02-16 19:23:35 tester x11-plugins/gaim-otr2008-02-16 19:23:36 tester x11-plugins/gaim-rhythmbox 2008-02-16 19:23:37 tester x11-plugins/gaim-slashexec 2008-02-16 19:23:38 tester x11-plugins/gaim-xfire 2008-02-16 19:23:39 tester x11-plugins/gaimosd 2008-02-16 19:23:39 tester x11-plugins/ignorance 2008-02-16 19:23:40 tester app-accessibility/festival-gaim 2008-02-16 19:24:57 tester net-im/gaim 2008-02-16 19:27:56 tester net-im/gaim-blogger 2008-02-16 19:27:57 tester net-im/gaim-bnet2008-02-16 19:27:58 tester net-im/gaim-meanwhile 2008-02-16 19:27:58 tester net-im/gaim-snpp2008-02-16 19:27:59 tester dev-ruby/http-access2 2008-02-17 18:53:37 flameeyes Additions: app-emulation/systemsim-cell2008-02-12 18:19:40 corsair dev-python/dap 2008-02-13 14:03:14 bicatali dev-python/pywebdav 2008-02-14 10:34:23 cedk sys-cluster/openais 2008-02-14 18:37:41 wschlich app-editors/efte2008-02-15 06:42:24 omp games-rpg/nwmovies 2008-02-17 00:55:47 calchan net-print/adobeps 2008-02-17 22:38:44 sbriesen -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Monday 18 February 2008 21:20:52 Donnie Berkholz wrote:
@@ -614,7 +614,7 @@
# @DESCRIPTION:
# DEPRECATED - Gets the flags needed for NOW binding
bindnow-flags() {
- ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild + ewarn QA: stop using the bindnow-flags function ...
simply drop it from your ebuild 2
This seems like something ewarn should do on its own.
baselayout and portage have always echoed ewarn to stdout and not stderr.
Warnings are NOT errors, so why use stderr? If it's an error, use eerror which
DOES goto stderr.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On 21:37 Mon 18 Feb , Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:20:52 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: This seems like something ewarn should do on its own. http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.121view=markup I'm not sure what I'm supposed to get out of this, besides seeing that a lot of stuff is sent to stderr. http://thread.gmane.org/gmane.linux.gentoo.user/194929 Right, I figured the reason was something along the lines of info going to stdout when only flags should. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Deprecating an eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 15:43:56 -0500 Doug Klima [EMAIL PROTECTED] wrote: Ok. I guess no one else has any feelings about this. Potentially doing something like: DEPRECIATED=$DEPRECATED $ECLASS Deprecated != depreciated. You caught my typo. You clearly still got the meaning of the e-mail... at the top of each deprecated eclass. In the end $DEPRECATED would have a list of all the eclasses that are deprecated? Maybe even: DEPRECATED_MYECLASS=myreplacement would mean that myeclass.eclass is replaced by myreplacement.eclass ? Well, that depends upon whether you want it to be part of the C/P-V metadata... If you do, it's a cache format change (and you can't easily do DEPRECATED_*). But then, deprecation is a property of the eclass, not an C/P-V. Deprecation is a property of the eclass. Not of an ebuild. The point is to allow utilities and users/developers to clearly see that an eclass is deprecated and what they should be using in place of it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Deprecating an eclass
On Mon, 18 Feb 2008 17:19:55 -0500 Doug Klima [EMAIL PROTECTED] wrote: Well, that depends upon whether you want it to be part of the C/P-V metadata... If you do, it's a cache format change (and you can't easily do DEPRECATED_*). But then, deprecation is a property of the eclass, not an C/P-V. Deprecation is a property of the eclass. Not of an ebuild. The point is to allow utilities and users/developers to clearly see that an eclass is deprecated and what they should be using in place of it. Right. eclasses don't currently have metadata (and there's no easy way for them to have it, since eclasses can't be sourced standalone). If you make deprecation a metadata variable, there will be no way for a package manager to determine whether an eclass is deprecated unless it has an ebuild that uses that eclass. Is this a satisfactory restriction? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
On Mon, 18 Feb 2008 16:26:11 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? I'd mutter something about EAPIs here, but really if people are having difficulty understanding the necessity of the original commit, I suspect it's a lost cause... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
Ciaran McCreesh wrote: On Mon, 18 Feb 2008 16:26:11 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 18 Feb 2008 13:54:34 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118r2=9140 Alright, so portage has put this stuff to stderr since January 4. Then why are we also adding workarounds to individual eclasses? How many people are running a Portage version released after January 4? Eventually, all of them. And until then, how many users are going to get things going weirdly wrong if workarounds aren't added to everything using the code? I'd mutter something about EAPIs here, but really if people are having difficulty understanding the necessity of the original commit, I suspect it's a lost cause... 6 -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Deprecating an eclass
On Monday 18 February 2008, Doug Klima wrote: Potentially doing something like: DEPRECIATED=$DEPRECATED $ECLASS at the top of each deprecated eclass. Adding deprecation info directly into the eclass file feels wrong to me. (Eclasses are free software after all and can be reused - ok, nobody will ever do that, but we're talking theory here - so we shouldn't put Gentoo policy in there.) What about /usr/portage/profiles/deprecated_eclasses looking like old_eclass_1,old_eclass_2:new_eclass_1,new_eclass_2 indicating that the old_eclasses have been deprecated by the new_eclasses. Having multiple eclasses deprecated by multiple eclasses may not be that common, but this kind of syntax allows for some grouping of related eclasses being replaced together. -- Torsten Rehn [EMAIL PROTECTED] Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Deprecating an eclass
Ciaran McCreesh kirjoitti: On Mon, 18 Feb 2008 17:19:55 -0500 Doug Klima [EMAIL PROTECTED] wrote: Well, that depends upon whether you want it to be part of the C/P-V metadata... If you do, it's a cache format change (and you can't easily do DEPRECATED_*). But then, deprecation is a property of the eclass, not an C/P-V. Deprecation is a property of the eclass. Not of an ebuild. The point is to allow utilities and users/developers to clearly see that an eclass is deprecated and what they should be using in place of it. Right. eclasses don't currently have metadata (and there's no easy way for them to have it, since eclasses can't be sourced standalone). If you make deprecation a metadata variable, there will be no way for a package manager to determine whether an eclass is deprecated unless it has an ebuild that uses that eclass. Is this a satisfactory restriction? A metadata.xml like file for eclasses could fit the bill. It could have both the maintainer info and the deprecation information among other things. Regards, Petteri signature.asc Description: OpenPGP digital signature
