Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On Fri, Nov 03, 2006 at 02:29:45AM -0500, Mike Frysinger wrote: this is not a implicit vs explicit thread; if you want that discussion start your own That discussion (dropping it to explicit, as has been discussed often enough) should be started off again since fixing it isn't exactly a matter of applying a patch and ignoring it so... swegener? Feel free to chime in, you were one of the main folks after killing implicit from what I recall. Meanwhile... we've said the relationship of DEPEND atoms in ebuilds should be independent of the DEPEND atoms found in eclasses as logically ebuilds should not care what it takes for eclasses to work and vice versa ... for the most part, this is true ... however, semi-recently, a change was made such that the implicit RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in any way ... that means if you have an ebuild at the moment that does: DEPEND=foo and you dont inherit any eclasses, then you also get for free: RDEPEND=foo if you decide to inherit eclasses though, you had better do some research as any eclass that does even RDEPEND= will change that behavior ... or if you are an eclass writer and you decided to add RDEPEND to your eclass, you had better do a reverse check and make sure that any ebuild that inherits your eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as you would have just broken it ... awesome ;) i posted a patch to fix this regression, but since it took so long before anyone noticed, zmedico wants to see if anyone is opposed (i dont know why they would be, but i cant think of everything) so to recap, the fix here changes it back to the historically documented behavior that the implicit RDEPEND happens in ebuilds regardless of what eclasses do Mildly screwed on this one from a cache standpoint; 1) the change went out unversioned, meaning that while it was spreading, folks were getting a mix of it. Likely their are still cache entries distributed with gentoo-x86 that are still old style deps. Nice. 2) Same issue via reverting it; it's an unversioned change, so portage will *not* pick up on it and fix it. Additionally, cause I was being anal about making --metadata as fast as possible, portage will *not* pick up the change since mtimes won't differ, thus will not write the new entry into the localized cache (cache.util.py, note the is_eclass_data_valid check controlling write_it boolean). #1 was stupid, #2 pretty royally gets us up the backside. So... my suggestion. Decide what you're going to do long term now, no more (bluntly) fucking around with this. Got a few courses of action from where I'm sitting- 1) EAPI bump for the restored behaviour. This sucks since it forces the entire tree to be bumped to force falling back to older behaviour (this is why changes like this are supposed to be EAPI bumped in the first place btw). 2) (several steps) 2.a) Revbump all afflicted portage versions with a patch restoring original behaviour, leaving keywords the same (meaning 2.1-r3 goes in with stable keywords); pull all portage versions that have the broken behaviour (=2.1 basically). 2.b) Force mtime touches of _all_ eclasses to force both rsync transfer within the mirror tier (can do this other ways), but more importantly, to force the transfer of all eclass consumers to the localized cache on folks machines. This at least gets them the old style deps in their cache. It will *not* fix the rdeps for overlay ebuilds that are afflicted, and does not fix it if the user triggers regeneration locally. 3) ignore it, and laugh like nero till everyone has upgraded to a fixed version of portage and enough churn in the tree has occured to have forced the corrected cache entries locally. #1 blows since either it requires changing EAPI in every ebuild ( easier, base/profile.bashrc, although I never intended profile bashrc to influence ebuild metadata), or auditing the rdeps and fixing them, bumping when after older behaviour. Additionally, requires leaving a portage version behind at the older EAPI for upgrading. #2 is fairly brutal initially, but should clear out the corruption pretty quickly for majority of users; for overlay users and devs however, it relies on folks upgrading to a fixed portage fairly quickly so that rdeps are proper. Doubly so for devs, since their portage installation is the first line of dependency verification (folks running automated repoman/pcheck dependency scans being second line). One upshot though, this method will push the proper deps into the localized cache for stage* users. Downside is that it triggers a pretty heavy hit on rsync mirrors, although the eclass touching can be stretched out over a few days to incrementally push out the updated cache. #3 means that broken rdeps linger for the next few months till folks have upgraded, and the mess has
[gentoo-dev] Re: Monthly Gentoo Council Reminder for November
Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I appreciate that many will be against this idea, but I'd still like to discuss it: a binary repository for gentoo. Yes, I know gentoo is a meta-distro. And that there isn't loads of bandwidth. That's easily got round. The main problem I see is USE flags (devs already compile with standard C-flags right?) but I was thinking about standardising for 2 or 3 types of network- SOHO, medium and large enterprise (eg for LDAP etc) would solve most cases. We can always tag pkgs with USE flags. If gentoo is still serious about enterprise adoption, it needs a binary repo (so we can avoid system breakage) which would of course be a little bit behind. I'd be happy to contribute time, as I'm sure many other users would. As to why I don't just do it myself, I think it's a bit silly to duplicate the compile that devs do anyway. There are, after all, other nice things about gentoo besides compiling from source, which would always remain a choice. I'm more interested in practical objections than philosophical debates, but as ever it's your free speech :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
this is not a implicit vs explicit thread; if you want that discussion
start
your own
we've said the relationship of DEPEND atoms in ebuilds should be independent
of the DEPEND atoms found in eclasses as logically ebuilds should not care
what it takes for eclasses to work and vice versa ... for the most part, this
is true ...
however, semi-recently, a change was made such that the implicit
RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in
any way ... that means if you have an ebuild at the moment that does:
DEPEND=foo
and you dont inherit any eclasses, then you also get for free:
RDEPEND=foo
The change occurred sometime between portage-2.0.51 and portage-2.0.52, and the
first stable version to have it was portage-2.0.53 (released in December of
2005). People didn't really start to notice the difference until after
portage-2.1 had been deployed on the master rsync mirror last June (it had been
running portage-2.0.51.22-r3 up until then).
if you decide to inherit eclasses though, you had better do some research as
any eclass that does even RDEPEND= will change that behavior ... or if you
are an eclass writer and you decided to add RDEPEND to your eclass, you had
better do a reverse check and make sure that any ebuild that inherits your
eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as
you would have just broken it ... awesome ;)
i posted a patch to fix this regression, but since it took so long before
anyone noticed, zmedico wants to see if anyone is opposed (i dont know why
they would be, but i cant think of everything)
so to recap, the fix here changes it back to the historically documented
behavior that the implicit RDEPEND happens in ebuilds regardless of what
eclasses do
-mike
If we do this then I want to make sure everybody is prepared for the
consequences. Basically, it restricts implicit RDEPEND to the ebuild level,
making it independent of whatever RDEPEND may or may not be defined in the
inherited eclasses. That means that some ebuilds will get implicit RDEPEND
that they don't get currently. Also, some ebuilds will loose some implicit
RDEPEND that they current get from eclasses.
I've attached the patch which reverts the behavior. If we do this, I think that
we should do it in one big sweep, via a sys-apps/portage revbump and a
simultaneous application of the patch on the master rsync mirror (see Brian
Harring's email for more details).
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFSwFI/ejvha5XGaMRArjaAKDi8B++F71vt3D2QkG5vyRhZ0yWvgCghBVA
ZrVSROlN0E7X/xdkFbJ6NXo=
=yRsF
-END PGP SIGNATURE-
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 4913)
+++ bin/ebuild.sh (working copy)
@@ -1504,8 +1504,8 @@
#syntax from getting expanded :)
#check eclass rdepends also.
set -f
-if [ ${RDEPEND-unset} == unset ] [ ${E_RDEPEND-unset} == unset ] ;
then
- export RDEPEND=${DEPEND} ${E_DEPEND}
+if [ ${RDEPEND-unset} == unset ]; then
+ export RDEPEND=${DEPEND}
debug-print RDEPEND: not set... Setting to: ${DEPEND}
fi
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On 2006-11-03 at 00:43 -0800, Zac Medico wrote: Also, some ebuilds will loose some implicit RDEPEND that they current get from eclasses. Why? I suppose more logical solution is to adjoin DEPEND from ebuild and RDEPEND from eclass. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov (pva) wrote: On 2006-11-03 at 00:43 -0800, Zac Medico wrote: Also, some ebuilds will loose some implicit RDEPEND that they current get from eclasses. Why? I suppose more logical solution is to adjoin DEPEND from ebuild and RDEPEND from eclass. Peter. You've misunderstood the meaning of implicit RDEPEND in my statement above (I don't blame you, implicit RDEPEND can be a confusing topic). When I say implicit RDEPEND, I am talking about DEPEND that has been implicitly converted to RDEPEND. Some ebuilds may currently have some implicit RDEPEND that originated as DEPEND in an eclass. If we use the patch to revert that behavior, those specific implicit RDEPEND atoms will go away. I hope this makes sense. :) Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFSw45/ejvha5XGaMRAntfAJ0X0K9U+CtyB4nhq73v8p5EBd5w8ACg8nc4 jN+Q4rWo+tfvoVL1YUY01E8= =X/2/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On Friday 03 November 2006 04:32, Peter Volkov (pva) wrote: On 2006-11-03 at 00:43 -0800, Zac Medico wrote: Also, some ebuilds will loose some implicit RDEPEND that they current get from eclasses. I suppose more logical solution is to adjoin DEPEND from ebuild and RDEPEND from eclass. that is the behavior that we'd be moving to -mike pgpQTpCNsh0rp.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On Friday 03 November 2006 03:23, Brian Harring wrote: so... so... start a new thread exactly like i told you so :P -mike pgpPwyBBW87wn.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for November
On Friday 03 November 2006 03:47, Steve Long wrote: If gentoo is still serious about enterprise adoption Gentoo as an entire whole is not really serious about anything last i checked, it was the server project who was working on the whole enterprise thing ... those guys are serious about targetting the enterprise so why do we need to discuss it ? -mike pgp6ljLg5STC1.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for November
Steve Long wrote: [Fri Nov 03 2006, 02:47:52AM CST] I appreciate that many will be against this idea, but I'd still like to discuss it: a binary repository for gentoo. Yes, I know gentoo is a meta-distro. And that there isn't loads of bandwidth. That's easily got round. It is? The main problem I see is USE flags (devs already compile with standard C-flags right?) but I was thinking about standardising for 2 or 3 types of network- SOHO, medium and large enterprise (eg for LDAP etc) would solve most cases. We can always tag pkgs with USE flags. If gentoo is still serious about enterprise adoption, it needs a binary repo (so we can avoid system breakage) which would of course be a little bit behind. I'd be happy to contribute time, as I'm sure many other users would. I think you'll find that there is little interest (among devs) in Gentoo maintaining a binary sub-distribution. My view, and for some time it's been our semi-official view, is that Gentoo can serve as a nice base for creating a binary distribution, and we encourage people to do so, but that it shouldn't be a part of Gentoo itself. (That said, it's true that there is still a real need for better support for binaries in portage, especially for handling USE conflicts.) As for Gentoo being serious about enterprise adoption, I don't agree that we need a binary repo. I think we ought to make it easy for our users to create and use their own, customized, distribution. That's our strength as a meta-distribution. (We also need to make it easy to install and replicate custom distributions, but we already have Catalyst and the Seeds project addressing those issues.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpNHFBr0M82S.pgp Description: PGP signature
[gentoo-dev] xelatex --- Can't load fontspec (no [EMAIL PROTECTED])
Josh,
As you recall, I discussed problems with \use{fontspec} in xelatex
with you earlier. I am copying gettoo-dev@ on the off chance other
people are playing with xelatex, too. People who have no idea what I am
talking about might as well stop reading now.
The difficulty is that fontspec in one instance uses
[EMAIL PROTECTED], and it's trying to decide between AAT and ICU.
Unfortunately, [EMAIL PROTECTED] is not defined anywhere. The solution
is to use [EMAIL PROTECTED] instead and to always use ICU. The little patch I
have attached does that.
With this change to fontspec.sty, under xelatex
\use{fontspec}
loads the style file as expected, and commands like
\setromanfont[BoldFont=Charis SIL Bold,ItalicFont=Charis SIL
Italic]{Charis SIL}
work the way they are supposed to. (And yes, you do need the double
because otherwise, xelatex stops scanning at the space and tries to load
Charis (not Charis SIL).)
Hope this is of interest,
Regards,
Ferris
--
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Devrel, Sparc)
--- texmf/tex/xelatex/fontspec/fontspec.sty- 2006-11-01 20:22:18.0 +
+++ texmf/tex/xelatex/fontspec/fontspec.sty 2006-11-03 14:20:18.0 +
@@ -500,8 +500,12 @@
[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED],#1}\fi
[EMAIL PROTECTED]@family{scfeat:[EMAIL PROTECTED] #1 [EMAIL PROTECTED]
[EMAIL PROTECTED],ICU}{%
- [EMAIL PROTECTED]@suffix/#1}%
[EMAIL PROTECTED],ICU}{%
+% [EMAIL PROTECTED]@suffix/#1}%
+% [EMAIL PROTECTED][EMAIL PROTECTED]@suffix at [EMAIL PROTECTED] pt
+% [EMAIL PROTECTED]@[EMAIL PROTECTED]@long +rend:#1}}
[EMAIL PROTECTED]
+ [EMAIL PROTECTED]@suffix/ICU}%
[EMAIL PROTECTED][EMAIL PROTECTED]@suffix at [EMAIL PROTECTED] pt
[EMAIL PROTECTED]@[EMAIL PROTECTED]@long +rend:#1}}
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Removal of sci-biology/cbcanalyzer
Hi everyone, sci-biology/cbcanalyzer no longer compiles on any of my systems (bug #153881). It is unmaintained and I have no interest in fixing it. It has been package.mask'ed for a while and no one noticed. Unless someone is interested in fixing the bug and maintaining the package in the future, I will remove it from Portage in about a month. Regards, -- Olivier Fisette (ribosome) Gentoo Linux Developer Scientific applications, Developer relations pgphw2qABeAOW.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On Fri, 3 Nov 2006 02:29:45 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: so to recap, the fix here changes it back to the historically documented behavior that the implicit RDEPEND happens in ebuilds regardless of what eclasses do Do it please. The current behaviour is retarded however you look at it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On Friday 03 November 2006 08:29, Mike Frysinger wrote:
so to recap, the fix here changes it back to the historically documented
behavior that the implicit RDEPEND happens in ebuilds regardless of what
eclasses do
Fine by me, that would probably solve quite a bit of problems (and although I
tried, I can't think of a way how restoring this will break stuff.. the worse
it can do is making pointless some extra DEPEND=${RDEPEND} or vice-versa in
ebuilds).
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...
pgpoYnauUuZlW.pgp
Description: PGP signature
[gentoo-dev] Retirement
I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Retirement
On Fri, Nov 03, 2006 at 02:15:58PM -0500, Jon Portnoy wrote: And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Good to hear the really important packages are in good hands. :-) Later. It's been fun, it's been real, but it hasn't been real fun. :) Too bad to see you go, thanks for the stuff you did to^Wfor Gentoo. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpcvhwRN4beP.pgp Description: PGP signature
Re: [gentoo-dev] Retirement
On Fri, Nov 03, 2006 at 02:15:58PM -0500, Jon Portnoy wrote: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. Sad to see another of the old faces leave. Best of luck in whatever it is you choose to spend your time on. -pete -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Retirement
Wow, this retirement f*cks me up some, I have to say. I'll give you a better send off on the planet blogs, because for now I'm still reeling from the news. I'll miss you, that's for sure. -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Retirement
Jon Portnoy wrote: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. So long, thanks for all you've done. Thanks too for f-m-g-dev, too. :D. Good luck! signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Retirement
Tach Seemant, 0x2B859DE3 (PGP-PK-ID) Seemant Kulleen schrieb: Wow, this retirement f*cks me up some, I have to say. I'll give you a better send off on the planet blogs, because for now I'm still reeling from the news. Hey, you could write a praise for new devs...for me e.g. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Retirement
On Friday 03 November 2006 20:15, Jon Portnoy wrote: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. I feel a bid sad to see you go. Even sadder that because of legalities you never got to serve on the board of trustees. For the rest, all the best of luck and see you around. Greetings, Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpoVl6oTu06M.pgp Description: PGP signature
Re: [gentoo-dev] Retirement
Jon Portnoy wrote: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. Thanks for everything, Jon. You've been a great friend and will continue to be. That's more meaningful than any of the work we've done. Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Retirement
Jon Portnoy [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 03 Nov 2006 14:15:58 -0500: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. Wow, I think I'm learning what it feels like to be old, and see all the folks you knew before retiring and going elsewhere. I'm just a user, but this announcement stings! Wishing you well wherever you go. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
