Re: [gentoo-dev] g-cpan
On Tue, Jun 09, 2009 at 02:57:31AM +0200, Benny Pedersen wrote: > i like to use g-cpan more, but as lately it seems not to be so much stable > with latest portage :/ > > my question is how to make a bug on it or even if its worth doing it, is > there a better proper way of make cpan modules into ebuilds as it was one > time ? File a bug if there is something wrong - however it's not broken for me at the moment. It just goes to p...@gentoo.org. AFAIK when I last asked, g-cpan didn't have an actual maintainer. I strongly suggest my patch from bug 239217 if you use it lots. My personal copy has probably diverged a fair bit from the latest ebuild. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp93L6XZAKwM.pgp Description: PGP signature
Re: [gentoo-dev] g-cpan
On Tue, Jun 9, 2009 at 12:57 PM, Benny Pedersen wrote: > > i like to use g-cpan more, but as lately it seems not to be so much stable > with latest portage :/ > > my question is how to make a bug on it or even if its worth doing it, is > there a better proper way of make cpan modules into ebuilds as it was one > time ? > I've just taken to DIYing it and making them suitable enough to go into the overlay. http://gist.github.com/126197 , I tend to run that, then just work out the depends by reading upstreams Makefile.PL /Meta.yaml . Feel free to adjust to your liking. Probably sounds a bit archaic, but I've gotten used to it, g-cpan and everything else that's existed seemed to explode too often for my liking. -- Kent perl -e "print substr( \"edrgmaM SPA nocomil.i...@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
On Tuesday 09 June 2009, Mike Frysinger wrote: > On Monday 08 June 2009 18:25:18 Robert Buchholz wrote: > > And personally, I hate having to enable USE=png on all my desktop > > machines so I can use a desktop background > > eh ? USE=png is in all default desktop profiles ... You are correct, I should choose my examples better. Good default. Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] g-cpan
i like to use g-cpan more, but as lately it seems not to be so much stable with latest portage :/ my question is how to make a bug on it or even if its worth doing it, is there a better proper way of make cpan modules into ebuilds as it was one time ? -- http://localhost/ 100% uptime and 100% mirrored :)
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 20:44:35 Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 07:42:17PM -0400, Mike Frysinger wrote:
> > > One of the reasons to move stuff OUT of /lib are all the profiles where
> > > SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> > > systems (so there is no lib23/64) or multilib systems where /lib is the
> > > correct location, then any test against /lib/rc/version would be fine.
> > > On anything else, it's not.
> > >
> > > Having it in a different location from upstream (OpenRC), means that
> > > any other distributions using OpenRC's /libexec/rc/version location
> > > would need to patch all their init.d scripts.
> >
> > the proposed /sbin/functions.sh check would makes this issue moot
>
> And why the hell didn't you come forward on bug 270646 with this?
i'm busy, deal
> I'm concerned that absence tests like that will not be as useful as
> OpenRC spreads. Sure in Gentoo, baselayout1 provides /sbin/functions.sh,
> but other users won't.
i dont see how that is relevant. we only care about Gentoo here. plus, the
test is: if /sbin/functions.sh exists, it's baselayout-1 (which no one else
outside of Gentoo will be using), otherwise it's openrc. once we toss
baselayout-1, there is no test as everything requires openrc.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Mon, Jun 08, 2009 at 07:42:17PM -0400, Mike Frysinger wrote:
> > One of the reasons to move stuff OUT of /lib are all the profiles where
> > SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> > systems (so there is no lib23/64) or multilib systems where /lib is the
> > correct location, then any test against /lib/rc/version would be fine.
> > On anything else, it's not.
> >
> > Having it in a different location from upstream (OpenRC), means that any
> > other distributions using OpenRC's /libexec/rc/version location would
> > need to patch all their init.d scripts.
> the proposed /sbin/functions.sh check would makes this issue moot
And why the hell didn't you come forward on bug 270646 with this?
I'm concerned that absence tests like that will not be as useful as
OpenRC spreads. Sure in Gentoo, baselayout1 provides /sbin/functions.sh,
but other users won't.
Since /libexec and /lib are out for the discussed reasons, this leaves
us coming back to /etc/openrc-version, with the same file in
CONFIG_PROTECT_MASK.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpoSvl60ZgYe.pgp
Description: PGP signature
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
On Monday 08 June 2009 18:25:18 Robert Buchholz wrote: > And personally, I hate having to enable USE=png on all my desktop > machines so I can use a desktop background eh ? USE=png is in all default desktop profiles ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
Maciej Mrozowski wrote: While it usually doesn't do any particular harm (but I guess security and prefix/alt team won't agree on this) - insanely enabling everything by default The Prefix team does not care either way. is not the best idea in my opinion. Of course we need an example. Let's have a look at latest stable media- video/mplayer-1.0_rc2_p20090322 ebuild: IUSE="3dnow 3dnowext +a52 +aac aalib +alsa altivec +amrnb +amrwb arts +ass bidi bindist bl +cddb +cdio cdparanoia -cpudetection -custom-cflags -custom-cpuopts debug dga +dirac directfb doc +dts +dv dvb +dvd +dvdnav dxr3 +enca +encode esd +faac +faad fbcon ftp gif ggi -gtk +iconv ipv6 jack joystick jpeg kernel_linux ladspa libcaca lirc +live lzo mad md5sum +mmx mmxext mng +mp2 +mp3 musepack nas +nemesi +network openal +opengl oss png pnm pulseaudio pvr +quicktime radio +rar +real +rtc -samba +schroedinger sdl +speex sse sse2 ssse3 svga teletext tga +theora +tremor +truetype +unicode v4l v4l2 vdpau vidix +vorbis -win32codecs +X +x264 xanim xinerama +xscreensaver +xv +xvid xvmc zoran" Personally I'd really like to hear some explanation from maintainers about the reasons mplayer needs all those dependencies or why they are *really* recommended for every user of *any* profile (let me remind this). But thats's not the point - the point is, Gentoo probably needs some policy to advise, when some newly added USE flags are appropriate to be enabled by default. I suggest as follows: - When newly added USE flag makes already provided feature optional - needs to be enabled by default (this is required to make package feature set somewhat invariant after update) - When newly added USE flag adds new feature that is considered very common (that's tricky part and decision should be always made by herd, not individual developer) *but* *does* *not* *pull* *any* *dependencies* - enable by default - in any other case *do* *not* *enable* by default - (why? because "I use it so I'll enable it by default" is not enough of an explanation) What's the opinion on that? I guess we need some policy or at least some suggestion mentioned in devmanual - really.. IUSE defaults or USE defaults in profiles..Either way...someone will complain. This is why you can disable flags in package.use, *or* select a non-desktop profile. meh.. -Jeremy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 19:23:01 Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
> > > >> Also, should Gentoo (Linux) never break with tradition even if
> > > >> somethings are better elsewhere?
> > > >
> > > > no, there is no "innovation" here nor any incentive to do so. i also
> > > > personally dont believe in /usr/libexec/, so i'm not going to
> > > > randomly be convinced by /libexec/ in the meantime.
> > >
> > > The "innovation" here being shell scripts and text files are not 32/64
> > > bit dependent and thus don't belong in a directory clearly marked as
> > > such.
> >
> > ABI is really not the driving force behind libexec vs lib, nor does it
> > really matter here. openrc isnt a multilib package nor does it need to
> > be.
>
> Even while it isn't a multilib package, there's precedent to move stuff
> out of /lib (/usr/lib etc).
not really. the precedent is to move from / to /usr. we havent really cared
about anything else (ignoring correctness of moving state files to /var).
> One of the reasons to move stuff OUT of /lib are all the profiles where
> SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> systems (so there is no lib23/64) or multilib systems where /lib is the
> correct location, then any test against /lib/rc/version would be fine.
> On anything else, it's not.
>
> Having it in a different location from upstream (OpenRC), means that any
> other distributions using OpenRC's /libexec/rc/version location would
> need to patch all their init.d scripts.
the proposed /sbin/functions.sh check would makes this issue moot
> vapier: I take it by this entire discussion that you aren't going take
> the rest of OpenRC's move of scripts to /libexec either?
ive already added that change to the openrc- to keep things in /lib/rc/
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
> > >> Also, should Gentoo (Linux) never break with tradition even if
> > >> somethings are better elsewhere?
> > > no, there is no "innovation" here nor any incentive to do so. i also
> > > personally dont believe in /usr/libexec/, so i'm not going to randomly be
> > > convinced by /libexec/ in the meantime.
> > The "innovation" here being shell scripts and text files are not 32/64
> > bit dependent and thus don't belong in a directory clearly marked as such.
> ABI is really not the driving force behind libexec vs lib, nor does it really
> matter here. openrc isnt a multilib package nor does it need to be.
Even while it isn't a multilib package, there's precedent to move stuff
out of /lib (/usr/lib etc).
One of the reasons to move stuff OUT of /lib are all the profiles where
SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
systems (so there is no lib23/64) or multilib systems where /lib is the
correct location, then any test against /lib/rc/version would be fine.
On anything else, it's not.
Having it in a different location from upstream (OpenRC), means that any
other distributions using OpenRC's /libexec/rc/version location would
need to patch all their init.d scripts.
vapier: I take it by this entire discussion that you aren't going take
the rest of OpenRC's move of scripts to /libexec either?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpEzF8o08KRQ.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Council 2009/2010 - Nominations are now open
On Mon, Jun 08, 2009 at 01:49:38PM +0100, Steven J Long wrote: > Jorge Manuel B. S. Vicetto wrote: > > I'd like to second: amne solar grobian leio and darkside > and nominate: robbat2 As I present trustees, I cannot take this position. I've been on the council before, some years ago, during the CoC debacle, and while I feel I can contribute to the technical work of the council, I don't need to be on the council to get that work done. Try again after my trustees term is over. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpKtUtEI1k5O.pgp Description: PGP signature
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
On Monday 08 June 2009, Maciej Mrozowski wrote: ... > While it usually doesn't do any particular harm (but I guess security > and prefix/alt team won't agree on this) - insanely enabling > everything by default is not the best idea in my opinion. The Security Team supports all use flag combinations, even those not enabled by default. Masked use flags are not supported. As far as proactively disabling certain codecs go, that certainly exploits of certain (disabled) codecs. However, if the user was tricked into downloading a file and will see that he cannot play it due to a missing codec, he might just enable that use flag and rety. The only way to be safe is to minimize the untrusted input to your application, keep it updated, and employ other means of hardening (privilege separation). > Of course we need an example. Let's have a look at latest stable > media- video/mplayer-1.0_rc2_p20090322 ebuild: ... > Personally I'd really like to hear some explanation from maintainers > about the reasons mplayer needs all those dependencies or why they > are *really* recommended for every user of *any* profile (let me > remind this). You should see the list of referenced bug reports in the ChangeLog for an explanation: https://bugs.gentoo.org/show_bug.cgi?id=260588 As stated there, all internally supported codecs are enabled, and only very few default USE flags require external deps. > But thats's not the point - the point is, Gentoo probably needs some > policy to advise, when some newly added USE flags are appropriate to > be enabled by default. > > I suggest as follows: > - When newly added USE flag makes already provided feature optional - > needs to be enabled by default (this is required to make package > feature set somewhat invariant after update) > - When newly added USE flag adds new feature that is considered very > common (that's tricky part and decision should be always made by > herd, not individual developer) *but* *does* *not* *pull* *any* > *dependencies* - enable by default - in any other case *do* *not* > *enable* by default - (why? because "I use it so I'll enable it by > default" is not enough of an explanation) > > What's the opinion on that? I guess we need some policy or at least > some suggestion mentioned in devmanual - really.. I am in favor of applying common sense (hah!). An application (and an OS, in general) in the default config should run the common use cases, and some more. It's just as easy to remove a use flag as it is to enable it. And personally, I hate having to enable USE=png on all my desktop machines so I can use a desktop background. Just as much as I hate downloading some video and realizing I forgot to add USE=schroedinger for mplayer, and then wait for a recompile before the fun. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Enough about GLEP5{4,5}
[Answering to a random posting in this thread.] Please, stop this now, or continue your discussion in private. Thanks Ulrich
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
On Monday 08 June 2009 16:12:23 Maciej Mrozowski wrote: > I'd like to raise your attention on problem of in my opinion overusing IUSE > defaults in various packages. > Currently there seems to be no policy whatsoever at least advising when > it's appropriate to add + and when not, so it's just up to > developer's taste. the loose policy is to have the defaults follow what upstream intended. otherwise, it is left up to the maintainer on purpose -- they're supposed to know best. > While it usually doesn't do any particular harm (but I guess security and > prefix/alt team won't agree on this) - insanely enabling everything by > default is not the best idea in my opinion. > Of course we need an example. Let's have a look at latest stable media- > video/mplayer-1.0_rc2_p20090322 ebuild: mplayer and friends is a bad example. upstream wants a lot of things enabled by default. > But thats's not the point - the point is, Gentoo probably needs some policy > to advise, when some newly added USE flags are appropriate to be enabled by > default. we already have one -mike
Re: [gentoo-dev] Enough about GLEP5{4,5}
On Monday 08 of June 2009 22:41:12 Patrick Lauer wrote: >[snip] Thanks for your useless statistics. -- Cheers Dawid
Re: [gentoo-dev] Enough about GLEP5{4,5}
On Monday 08 June 2009 20:35:22 Ciaran McCreesh wrote: > On Mon, 08 Jun 2009 19:17:56 +0100 > > And how much developer time would be wasted to do so, and indeed has > > already been wasted on this? > Thanks to emails like yours, lots. 5-2009, 800 emails 11.75% ciaran.mccreesh.googlemail.com 4-2009, 287 emails 11.50% ciaran.mccreesh.googlemail.com 3-2009, 602 emails 9.47% ciaran.mccreesh.googlemail.com Congratulations. You managed to consistently hit the top spot for three months in a row, outrunning the second by a wide margin. At this rate of increase you'll write all emails on this mailing list somewhere near 2012 ... Source: http://archives.gentoo.org/stats/gentoo-dev-per-month.xml > > (If you don't think it is a problem, please feel free to say > > so /without/ resorting to insult over reason. If you think the > > proposal had merit: how come we've only now got agreement that > > easily-extractable EAPI works?) > > Easily-extractable EAPI either has change scope limitations or a > considerable performance impact. I thought the performance impact was still up for debate (and if I'm not mistaken the parsing approach would still be _much_ faster than the current sourcing approach, negating your argument quite nicely ...) > > GLEP 55's getting nowhere because a small group of religious fanatics > are doing anything they can to derail it because it came from "the > wrong people". No, you are ignoring what people say again. It's a bad idea, has nothing to do with your abrasive demeanor, your attempts to deflect the discussion etc. Amazingly people don't care that much about you. > If you want to know the kind of arguments that are being > thrown against GLEP 55 now, just have a look at: > > 22:54 < ciaranm> it's been established by precedent that gleps propose > an enhancement, and that competing enhancements get their own gleps > 22:55 < bonsaikitten> well, we claim precedent on this one > 22:55 < bonsaikitten> so there :) > 22:55 < ciaranm> point to your precedent please > 22:55 < bonsaikitten> it is the precedent > 22:56 < ciaranm> bonsaikitten: uh... i don't think you know what that > means.. > 22:56 < bonsaikitten> ciaranm: you refuse to accept time travel > > Yup, the argument of the week against GLEP 55 is that we refuse to > accept time travel. Oh, you took that little joke seriously. I thought you were joking there, precedent is such a funny and obsolete legal concept. Plus you had been baiting NeddySeagoon for almost an hour at that point, driving the discussion in circles without contributing any constructive comments or fact-based chains of reasoning. And you didn't quote the much better joke: time flies like an arrow, and fruit flies like banana That you now take a joke as a serious argument to show that "the others" are wrong is quite hilarious. I do wonder though why you feel the need to diffuse a technical discussion with humoristic things like this ... Still leaves open why you religiously deny any input from me, even if it could solve the problem, and why you try to remove the discussion of alternatives from GLEP55 when NeddySeagoon spent lots of time refining it after multiple people stated the simple problem that it is missing the discussion of alternatives and is not fit for discussion. So maybe you should just let go of this one and let people with experience in documentation, standardization and other similar things fight out this one? Might make it easier to get somewhere.
Re: [gentoo-dev] GLEP 55 Version 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.06.08 16:48, Ferris McCormick wrote: [snip] > Very small point. There is a difference between "EAPI in the file > name > extension" and just "EAPI in the file name". I think the intent here > is > the latter, but it speaks of them interchangeably it seems. > > Regards, > Ferris > -- > Ferris McCormick (P44646, MI) > Developer, Gentoo Linux (Sparc, Userrel, Trustees) > Ferris, Its not a small point, it makes quite a difference. In most places the glep should talk about "EAPI in the file name", not "EAPI in the file name extension". dev-zero got to me first on that and I need to update the glep. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkotc4EACgkQTE4/y7nJvatWFwCeIyq5Ks/WzTUImTJXaoRQG5Pc x5QAnjOm+jfgQ5/3vBqJyPsRDOtc6YCF =yoel -END PGP SIGNATURE-
Re: [gentoo-dev] Enough about GLEP5{4,5}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.06.08 19:35, Ciaran McCreesh wrote: [snip] > Easily-extractable EAPI either has change scope limitations or a > considerable performance impact. That needs to be quantified. e.g. 20ms to 200ms is a factor of 10x but it would not be considered 'considerable'. ms == 0.001 seconds > > GLEP 55's getting nowhere because a small group of religious fanatics > are doing anything they can to derail it because it came from "the > wrong people". [snip] I don't accept that. as I said in -council last night. A good technical paper presents an impartial, convincing technial argument. Glep 55 version 1.5 fails, as evidenced by the number of people who are not convinced that the problem it addresses exists, never mind the proposed solution. There are several issues. Some with glep55 and some with the glep process. Glep 55 (any version) does not cover all the areas in http://www.gentoo.org/proj/en/glep/glep-0001.html#what-belongs-in-a- successful-glep and it needs to. Glep 55 is a particularly complex glep. its not really suited to the current glep process which is written as if you agree everying during the process of writing the glep and its a done deal when it gets to council. Glep 55 would benefit from being subject to the full rigours of the life cycle process, which has already started to happen. Council have agreed the problem is worth addressing. Thats the first step in the process. We have several options to solve the acknowledged problem. Thats the next life cycle process step. They need to be presented first for peer review, then to council with some metrics on the bottlenecks of each. That does not mean you need fully working solutions. With that information, one solution will be selected for implementaion. Breaking the problem into small pieces and addressing each piece is the way complex problems are solved outside of Gentoo. At the top level its called Systems Engineering. I'm quite happy to do the editorial work but I need the facts to work with and after two years we still only have subjective assessments of the alternatives. Glep55 will be rejected no matter who presents it and where the ideas come from if its presented on one piece, its just too much to take in in one go. The approvers need to poke at the glep as it develops, not be presented with a done deal. > > -- > Ciaran McCreesh > - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkotcqcACgkQTE4/y7nJvatl/QCg3TwEohuKnT1xG8fgTybAs9DU vq0AoLyui1F3OQ5xChZAXCLQK12GefQA =PP28 -END PGP SIGNATURE-
[gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
Hi I'd like to raise your attention on problem of in my opinion overusing IUSE defaults in various packages. Currently there seems to be no policy whatsoever at least advising when it's appropriate to add + and when not, so it's just up to developer's taste. While it usually doesn't do any particular harm (but I guess security and prefix/alt team won't agree on this) - insanely enabling everything by default is not the best idea in my opinion. Of course we need an example. Let's have a look at latest stable media- video/mplayer-1.0_rc2_p20090322 ebuild: IUSE="3dnow 3dnowext +a52 +aac aalib +alsa altivec +amrnb +amrwb arts +ass bidi bindist bl +cddb +cdio cdparanoia -cpudetection -custom-cflags -custom-cpuopts debug dga +dirac directfb doc +dts +dv dvb +dvd +dvdnav dxr3 +enca +encode esd +faac +faad fbcon ftp gif ggi -gtk +iconv ipv6 jack joystick jpeg kernel_linux ladspa libcaca lirc +live lzo mad md5sum +mmx mmxext mng +mp2 +mp3 musepack nas +nemesi +network openal +opengl oss png pnm pulseaudio pvr +quicktime radio +rar +real +rtc -samba +schroedinger sdl +speex sse sse2 ssse3 svga teletext tga +theora +tremor +truetype +unicode v4l v4l2 vdpau vidix +vorbis -win32codecs +X +x264 xanim xinerama +xscreensaver +xv +xvid xvmc zoran" Personally I'd really like to hear some explanation from maintainers about the reasons mplayer needs all those dependencies or why they are *really* recommended for every user of *any* profile (let me remind this). But thats's not the point - the point is, Gentoo probably needs some policy to advise, when some newly added USE flags are appropriate to be enabled by default. I suggest as follows: - When newly added USE flag makes already provided feature optional - needs to be enabled by default (this is required to make package feature set somewhat invariant after update) - When newly added USE flag adds new feature that is considered very common (that's tricky part and decision should be always made by herd, not individual developer) *but* *does* *not* *pull* *any* *dependencies* - enable by default - in any other case *do* *not* *enable* by default - (why? because "I use it so I'll enable it by default" is not enough of an explanation) What's the opinion on that? I guess we need some policy or at least some suggestion mentioned in devmanual - really.. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Enough about GLEP5{4,5}
On Mon, 08 Jun 2009 19:17:56 +0100 Steven J Long wrote: > If the problem had been adequately communicated in the first place > (which is pretty much required for any proposal ime) instead of people > being told they "don't understand so go away" we could have agreed > then, that the issue was simply about knowing the EAPI before > sourcing. That is not what the issue is. That is half of what the issue is. > As it is, we _finally_ have grudging submission that tightening the > PMS to reflect QA reality works but is not "the best solution." No, it would not be to reflect reality. We would have to tighten the rules in such a way that it breaks things people have already done, and if we were to do so it would either impose performance penalties or not allow us the full scope of changes, and it would still require us to wait a year or more before going ahead with any of these changes. > (Even though the case for changing version format has not been made, The Council disagrees. > the argument applies to the other incompatible changes affecting > global environment.) No, that's a separate issue, and does not have the same performance implications. > Firstly, and most significantly, this only applies when the mangler > does not have the ebuild metadata in cache. Not true. > Bear in mind portage automatically caches overlays > under /var/cache/edb You are confusing the dep cache with the metadata cache. They are not the same thing. > Secondly, for the mangler to determine the "best-visible", EAPI is > not the only item under consideration. So again, there is a lie > implicit: whether from cache or from file, the mangler will ALWAYS > need some metadata on the ebuilds; CPV + EAPI is insufficient. It currently, and will still with 55, require metadata from only *some* ebuilds (usually just one). You're talking about making it require metadata from all of the ebuilds. > At very best, all EAPI in filename (wherever it is) does, is limit > the set of ebuilds to those with a supported EAPI before the cache > has to be consulted. For Gentoo users (who update as recommended) > using Gentoo product, that's _every_ ebuild in the tree and overlays. Er, no. It means we only have to consult any file at all for the best version, and then go backwards down versions until we find a visible version. > So what practically are we accomplishing for our users? We are letting package manager people make the changes needed so that developers can write better ebuilds. > And how much developer time would be wasted to do so, and indeed has > already been wasted on this? Thanks to emails like yours, lots. > (If you don't think it is a problem, please feel free to say > so /without/ resorting to insult over reason. If you think the > proposal had merit: how come we've only now got agreement that > easily-extractable EAPI works?) Easily-extractable EAPI either has change scope limitations or a considerable performance impact. GLEP 55's getting nowhere because a small group of religious fanatics are doing anything they can to derail it because it came from "the wrong people". If you want to know the kind of arguments that are being thrown against GLEP 55 now, just have a look at: 22:54 < ciaranm> it's been established by precedent that gleps propose an enhancement, and that competing enhancements get their own gleps 22:55 < bonsaikitten> well, we claim precedent on this one 22:55 < bonsaikitten> so there :) 22:55 < ciaranm> point to your precedent please 22:55 < bonsaikitten> it is the precedent 22:56 < ciaranm> bonsaikitten: uh... i don't think you know what that means.. 22:56 < bonsaikitten> ciaranm: you refuse to accept time travel Yup, the argument of the week against GLEP 55 is that we refuse to accept time travel. -- Ciaran McCreesh signature.asc Description: PGP signature
Re:[gentoo-dev] GLEP 55 Version 2
O > > Date: Sat, 06 Jun 2009 23:31:47 +0100 > From: Roy Bamford > To: gentoo-dev@lists.gentoo.org > Subject: [gentoo-dev] GLEP 55 Version 2 > > > - -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ladies and Gentlemen, > > I've spent some time reading all of this years emails on GLEP55 and > added a few lines to version 1.5 which is the last offical version. > > The HTML version (not with the GLEP style sheet) is at > http://xrl.us/bevrnb (my devspace) > Its not ready to go to council as it still needs additional content > which I don't have the background to contribuite. My role in this > version of GLEP 55 has been interpretation and editorial. > Very small point. There is a difference between "EAPI in the file name extension" and just "EAPI in the file name". I think the intent here is the latter, but it speaks of them interchangeably it seems. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 10:00:23 Roy Marples wrote: > Mike Frysinger wrote: > > On Monday 08 June 2009 09:09:43 Roy Marples wrote: > >> Mike Frysinger wrote: > >>> if openrc versions are causing a level of incompatibility, then it > >>> should itself be setting up an env var for init.d scripts to key off of > >>> rather than having to figure out what's going on via the filesystem. > >>> the point of this thread is to detect baselayout-1 vs openrc only. > >> > >> RC_VERSION is available in 0.5.0 > >> However, for VServer it needs to be easily available without running > >> anything, hence this discussion. > > > > if it's in the execution environment of the init.d script,nothing was run > > You would have to ask the VServer team, but my understanding was they > needed to detect version of OpenRC in a container from the host before > the container is started. if systems need crazy restrictions, these things should be clearly documented (preferably in a file in the openrc tree itself). otherwise we waste time talking about stuff none of us have the foggiest clue about. so until the vserver team opts to chime in, i dont think there's anything left here. the original issue can be handled via sbin/functions.sh (unless someone has a reason why not) -mike
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: On Monday 08 June 2009 09:09:43 Roy Marples wrote: Mike Frysinger wrote: if openrc versions are causing a level of incompatibility, then it should itself be setting up an env var for init.d scripts to key off of rather than having to figure out what's going on via the filesystem. the point of this thread is to detect baselayout-1 vs openrc only. RC_VERSION is available in 0.5.0 However, for VServer it needs to be easily available without running anything, hence this discussion. if it's in the execution environment of the init.d script,nothing was run -mike You would have to ask the VServer team, but my understanding was they needed to detect version of OpenRC in a container from the host before the container is started. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 09:09:43 Roy Marples wrote: > Mike Frysinger wrote: > > if openrc versions are causing a level of incompatibility, then it should > > itself be setting up an env var for init.d scripts to key off of rather > > than having to figure out what's going on via the filesystem. the point > > of this thread is to detect baselayout-1 vs openrc only. > > RC_VERSION is available in 0.5.0 > However, for VServer it needs to be easily available without running > anything, hence this discussion. if it's in the execution environment of the init.d script,nothing was run -mike
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: if openrc versions are causing a level of incompatibility, then it should itself be setting up an env var for init.d scripts to key off of rather than having to figure out what's going on via the filesystem. the point of this thread is to detect baselayout-1 vs openrc only. RC_VERSION is available in 0.5.0 However, for VServer it needs to be easily available without running anything, hence this discussion. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 09:01:46 Roy Marples wrote: > Mike Frysinger wrote: > > i didnt see any real discussion of /sbin/functions.sh ... i dont recall > > there being a reason historically for not checking for this file to > > detect baselayout-1 vs openrc, and no one has complained about its usage > > in mdadm ... > > That works as a baselayout-1 vs openrc test. > However, there was, or will be, a need to detect OpenRC version as well > which that doesn't address. I don't know if that is needed right now > though. if openrc versions are causing a level of incompatibility, then it should itself be setting up an env var for init.d scripts to key off of rather than having to figure out what's going on via the filesystem. the point of this thread is to detect baselayout-1 vs openrc only. -mike
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: i didnt see any real discussion of /sbin/functions.sh ... i dont recall there being a reason historically for not checking for this file to detect baselayout-1 vs openrc, and no one has complained about its usage in mdadm ... That works as a baselayout-1 vs openrc test. However, there was, or will be, a need to detect OpenRC version as well which that doesn't address. I don't know if that is needed right now though. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: the original discussion made it sound like /etc/openrc-version always existed independent of libexec That is incorrect. Thanks Roy
[gentoo-dev] Re: Gentoo Council 2009/2010 - Nominations are now open
Jorge Manuel B. S. Vicetto wrote: I'd like to second: amne solar grobian leio and darkside and nominate: robbat2 As ever, I'm disappointed I can't nominate you, jmb. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
[gentoo-dev] Re: Re: GLEP 55 Version 2
Roy Bamford wrote: > On 2009.06.07 10:34, Ulrich Mueller wrote: >> > On Sun, 07 Jun 2009, Steven J Long wrote: >> >> > I'd just like to know what the implications would be for users if >> we >> > kept the .ebuild extension, and a new PMS were rolled out stating >> > that the mangler were allowed to find the EAPI without sourcing >> (and >> > giving the restrictions) once portage 2.2 was stable, or the >> ability >> > to handle this backported to 2.1.6, and issued in a release? >> >> Even if we do only a one-time change of the file extension, can we >> ever get rid of the old extension? Or are we then stuck with two >> extensions in the tree until the end of time? >> >> Let's assume for the moment that we change from ".ebuild" to ".eb". >> Then we obviously cannot change all ebuilds in the tree to ".eb", >> otherwise old Portage versions would see an empty tree and there >> would >> be no upgrade path. >> >> Or am I missing something? >> Sounds about right > > First, lets be clear that the upgrade path related problems are driven > by the EAPI change, not the .ebuild to .eb change. That serves only to > allow the new EAPI to be introduced immedately and hide the change from > older package managers > > To keep an upgrade path, package managers and their dependencies need > to use EAPI 0, 1 or 2. (EAPI 3 is not yet out) How far back should the > upgrade path extend? > Well given that EAPI 3 is not out, and that bash-4 is not even stable (and if anyone thinks we can rely on bash-4 in the next 6 months, they didn't learn anything from bash-3 imo) this sounds like it's a fair distance away. From discussion with Harring, EAPIs were not meant to come out very often; iirc he said something like maybe once a year. I concur with Duncan on a year, as you know. I appreciate you feel it should be longer, and am happy to go with whatever the consensus is. > As you suggest, even with .ebuild to .eb change.its not a clean break > with the past but would happen over time, with ebuilds for new package > versions being migrated to the new format. For example we would > have > foo-2.1-r1.ebuild > foo-3.0.eb > portage-2.3.ebuild > portage-3.0.eb > yuck. > Portage-2.3 will understand the later EAPI but will itself, use only > EAPI, 0, 1 or 2. > Just to be clear: portage-2.2 and later will be fine with any EAPI, with no change to any ebuilds, nor any new extension being needed. The change can easily be backported to 2.1.6, tho I suspect 2.2 will be stable fairly soon. > Thats just portage. The same reasoning applies to any other package > manager and there are at least three. This begs the question of how > friendly do we want to be to derivitive distros that use our tree but > their own package manager? > As friendly as we can be without hobbling our own development. Most of them appear to be fairly collaborative with Gentoo in any case. > Upgrade path issues need to be addressed in the GLEP. I will add > something like the above in the next version. > Wrt transitioning, can the eapi (PMS 5.2.2) and deprecated (5.2.3) files not be of use? I seem to recall the change from 2007.1 to 2008.0 for example; anyone using a deprecated profile can expect a massive warning the next time they try to do anything after sync'ing. Thanks again for your work; I appreciate that your time is valuable. Regards, Steve. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
i didnt see any real discussion of /sbin/functions.sh ... i dont recall there being a reason historically for not checking for this file to detect baselayout-1 vs openrc, and no one has complained about its usage in mdadm ... -mike
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 07:03:37 Roy Marples wrote: > Mike Frysinger wrote: > > On Monday 08 June 2009 06:35:37 Roy Marples wrote: > >> Mike Frysinger wrote: > >>> On Monday 08 June 2009 06:12:04 Roy Marples wrote: > Mike Frysinger wrote: > > On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: > >> 1. OpenRC will provide /libexec/rc/version, a text file containing > >> the version (possible including a git ID) of the release. > > > > that requires us to actually utilize /libexec/ which is not a Linux > > convention on any system ive ever seen. > > OpenRC works on systems other than Linux and uses the best hierarchy > it can to match them all. > >>> > >>> i know why you use it, but that doesnt mean Gentoo (Linux) should > >> > >> rhetorical: > >> Should Gentoo (FreeBSD)? > > > > that's for the Gentoo/BSD team to decide > > So you're now advocating the check being > > [ -f /etc/openrc-version -o -f /libexec/rc/version ] the openrc ebuild will always provide a file in /etc regardless of libexec path > Way to go. try not to douche up the thread > >> Also, should Gentoo (Linux) never break with tradition even if > >> somethings are better elsewhere? > > > > no, there is no "innovation" here nor any incentive to do so. i also > > personally dont believe in /usr/libexec/, so i'm not going to randomly be > > convinced by /libexec/ in the meantime. > > The "innovation" here being shell scripts and text files are not 32/64 > bit dependent and thus don't belong in a directory clearly marked as such. ABI is really not the driving force behind libexec vs lib, nor does it really matter here. openrc isnt a multilib package nor does it need to be. > >> Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have > >> to move the version file in the ebuild as it just won't work when you > >> pass LIBEXECDIR=/lib/rc to the make targets. > > > > if the make system doesnt have a way of controlling the root libexecdir > > path, sounds like the make system is limited and/or broken and in need of > > fixing > > Eh? I just told you it does. To keep the status quo with /libexec/rc vs > /lib/rc I provide a make knob. Now you want to move 1 specific file out > of /lib/rc (because it could be in /lib64 or /lib32 and not in /lib) and > into /etc because of the /lib brokenness. the original discussion made it sound like /etc/openrc-version always existed independent of libexec -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Apache herds needs your help
On Monday 08 June 2009, Benedikt Böhm wrote: > Hi all, > > currently I am the only active developer in the apache herd, but > quite busy with work and life, so I'd like to ask all of you to fix > bugs assigned to apache-bugs@ if you come across them/if they annoy > you etc, since i cannot keep up with bugs currently. I'd also like to > see more active members in the herd as well in the future, so that > bugs can be resolved in a reasonable time again. If you're > interested, feel free to add yourself to herds.xml and join > #gentoo-apache. I would like to raise special attention to the open security bugs: http://tinyurl.com/apache-security Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: On Monday 08 June 2009 06:35:37 Roy Marples wrote: Mike Frysinger wrote: On Monday 08 June 2009 06:12:04 Roy Marples wrote: Mike Frysinger wrote: On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: 1. OpenRC will provide /libexec/rc/version, a text file containing the version (possible including a git ID) of the release. that requires us to actually utilize /libexec/ which is not a Linux convention on any system ive ever seen. OpenRC works on systems other than Linux and uses the best hierarchy it can to match them all. i know why you use it, but that doesnt mean Gentoo (Linux) should rhetorical: Should Gentoo (FreeBSD)? that's for the Gentoo/BSD team to decide So you're now advocating the check being [ -f /etc/openrc-version -o -f /libexec/rc/version ] Way to go. Also, should Gentoo (Linux) never break with tradition even if somethings are better elsewhere? no, there is no "innovation" here nor any incentive to do so. i also personally dont believe in /usr/libexec/, so i'm not going to randomly be convinced by /libexec/ in the meantime. The "innovation" here being shell scripts and text files are not 32/64 bit dependent and thus don't belong in a directory clearly marked as such. Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have to move the version file in the ebuild as it just won't work when you pass LIBEXECDIR=/lib/rc to the make targets. if the make system doesnt have a way of controlling the root libexecdir path, sounds like the make system is limited and/or broken and in need of fixing Eh? I just told you it does. To keep the status quo with /libexec/rc vs /lib/rc I provide a make knob. Now you want to move 1 specific file out of /lib/rc (because it could be in /lib64 or /lib32 and not in /lib) and into /etc because of the /lib brokenness. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: > /usr isnt guaranteed to be mounted for all init.d scripts Right... Well, then the best choice is probably /etc out of the list [Roy pointed out] of the only OS-nonspecific dirs, unless we want to have a small executable script in /bin or /sbin that spits out the version. -Joe
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: > maybe, but since we arent going to use /libexec/ at this time, that means > /etc > is the next best place How about /usr/share/openrc/version? Since /usr/share is supposed to contain package-specific (but platform independent) files that are *not* meant to be modified (unlike /etc), seems like it might be a good place for it. -Joe
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Joe Peterson wrote: Mike Frysinger wrote: maybe, but since we arent going to use /libexec/ at this time, that means /etc is the next best place How about /usr/share/openrc/version? The only dirs that are guaranteed to be available at boot are /dev /etc /lib /bin /sbin Plus these OS specific dirs /proc (Linux) /sys (Linux-2.6) /libexec (the BSD family) Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 06:39:53 Joe Peterson wrote: > Mike Frysinger wrote: > > maybe, but since we arent going to use /libexec/ at this time, that means > > /etc is the next best place > > How about /usr/share/openrc/version? > > Since /usr/share is supposed to contain package-specific (but platform > independent) files that are *not* meant to be modified (unlike /etc), seems > like it might be a good place for it. /usr isnt guaranteed to be mounted for all init.d scripts -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 06:35:37 Roy Marples wrote: > Mike Frysinger wrote: > > On Monday 08 June 2009 06:12:04 Roy Marples wrote: > >> Mike Frysinger wrote: > >>> On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: > 1. OpenRC will provide /libexec/rc/version, a text file containing the > version (possible including a git ID) of the release. > >>> > >>> that requires us to actually utilize /libexec/ which is not a Linux > >>> convention on any system ive ever seen. > >> > >> OpenRC works on systems other than Linux and uses the best hierarchy it > >> can to match them all. > > > > i know why you use it, but that doesnt mean Gentoo (Linux) should > > rhetorical: > Should Gentoo (FreeBSD)? that's for the Gentoo/BSD team to decide > Also, should Gentoo (Linux) never break with tradition even if > somethings are better elsewhere? no, there is no "innovation" here nor any incentive to do so. i also personally dont believe in /usr/libexec/, so i'm not going to randomly be convinced by /libexec/ in the meantime. > Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have > to move the version file in the ebuild as it just won't work when you > pass LIBEXECDIR=/lib/rc to the make targets. if the make system doesnt have a way of controlling the root libexecdir path, sounds like the make system is limited and/or broken and in need of fixing -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: On Monday 08 June 2009 06:12:04 Roy Marples wrote: Mike Frysinger wrote: On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: 1. OpenRC will provide /libexec/rc/version, a text file containing the version (possible including a git ID) of the release. that requires us to actually utilize /libexec/ which is not a Linux convention on any system ive ever seen. OpenRC works on systems other than Linux and uses the best hierarchy it can to match them all. i know why you use it, but that doesnt mean Gentoo (Linux) should rhetorical: Should Gentoo (FreeBSD)? Also, should Gentoo (Linux) never break with tradition even if somethings are better elsewhere? Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have to move the version file in the ebuild as it just won't work when you pass LIBEXECDIR=/lib/rc to the make targets. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 06:00:14 Roy Marples wrote: > Robin H. Johnson wrote: > > On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote: > IIRC vapier patched busybox to alias [[ to [, which is worse as you > still have to quote correctly as if [ and you don't get the =~ operator > from [[. i reverted that from busybox' ash a while ago > > I'm all for going with something that will work more globally, IFF it > > can be easily tested for (on pure Gentoo Linux machines, which is what > > most developers are running, because they won't be bothered to test > > under G/FBSD or Prefix/OSX etc), vs. just going by what the > > specification says. > > The only available shell on Linux that doesn't do anything other than > the POSIX spec is dash. However, even that shell is not entirely > compliant (a few missing features last I looked). and a few extra :p busybox' hush is pretty good, but not as widely tested yet -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 Version 2
On Sat, 2009-06-06 at 23:31 +0100, Roy Bamford wrote: > I've spent some time reading all of this years emails on GLEP55 and > added a few lines to version 1.5 which is the last offical version. Is there a specific reason not to include the "inherit eapi"[1][2] thing? IMHO this would fit best in "Abstract Solution (Part 1)" somehow like: -There are two potential solutions to this part of the problem, +There are three potential solutions to this part of the problem, * wait for old package managers to fall into disuse * 'blind' old package managers to ebuilds using later constructs + * use "inherit" to have old package managers almost silently + ignore unsupported ebuilds [1] http://archives.gentoo.org/gentoo-dev/msg_b2656aca1d124658b3df73d3d6804b7e.xml [2] http://archives.gentoo.org/gentoo-dev/msg_348f84690f03e597fb14d6602337c45f.xml Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Monday 08 June 2009 06:12:04 Roy Marples wrote: > Mike Frysinger wrote: > > On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: > >> 1. OpenRC will provide /libexec/rc/version, a text file containing the > >>version (possible including a git ID) of the release. > > > > that requires us to actually utilize /libexec/ which is not a Linux > > convention on any system ive ever seen. > > OpenRC works on systems other than Linux and uses the best hierarchy it > can to match them all. i know why you use it, but that doesnt mean Gentoo (Linux) should > Linux has /usr/libexec and I see no reason why it cannot exist on / for > when /usr is not available like other OS's do. > > Robin asked for an upstream decision of where to place the version file > and in the OpenRC world the best place is /libexec as /etc is just meant > for user configuration. maybe, but since we arent going to use /libexec/ at this time, that means /etc is the next best place -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: 1. OpenRC will provide /libexec/rc/version, a text file containing the version (possible including a git ID) of the release. that requires us to actually utilize /libexec/ which is not a Linux convention on any system ive ever seen. OpenRC works on systems other than Linux and uses the best hierarchy it can to match them all. Linux has /usr/libexec and I see no reason why it cannot exist on / for when /usr is not available like other OS's do. Robin asked for an upstream decision of where to place the version file and in the OpenRC world the best place is /libexec as /etc is just meant for user configuration. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Robin H. Johnson wrote: On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote: Roy: [[ or [? Entirely depends on system. OpenRC uses /bin/sh to process the actual init script. We rely on /bin/sh claiming POSIX compat [1]. On Gentoo Linux systems, this is normally a link to bash, so you can use bashisms if you so wish. Is "[[" a bashism or not? That's all I'm asking. What's a good way to test for POSIX compatibility so that the testing CAN actually be done. My testcase was 'bash --posix'. Testing under busybox's ash seems to work perfectly with "[[" as well. bash(1) only documents the --posix option to modify how bash starts up. It does not mention restricting bash extensions such as [[ IIRC vapier patched busybox to alias [[ to [, which is worse as you still have to quote correctly as if [ and you don't get the =~ operator from [[. But as you asked, here's what the good doc [1] has to say The following words may be recognized as reserved words on some implementations (when none of the characters are quoted), causing unspecified results: [[ ]] function select In other words, I won/t make any claims whether [[ ]] works in OpenRC. That doesn't answer if it's a bashism. I interpret that part of the document to simply be that it's implementation detail is not covered by the POSIX spec. If it's not in the spec, then it has to be an extension. Thus, if bash is extending it then it's a bashism. I'm all for going with something that will work more globally, IFF it can be easily tested for (on pure Gentoo Linux machines, which is what most developers are running, because they won't be bothered to test under G/FBSD or Prefix/OSX etc), vs. just going by what the specification says. The only available shell on Linux that doesn't do anything other than the POSIX spec is dash. However, even that shell is not entirely compliant (a few missing features last I looked). Just Do What The Fuck You Like, Just Don't Bug Me pretty much somes up my attitude right now. Why do I have this attiude? Well, bug #175783 is a very good example. It's over two years since I submitted replacement scripts and did more besides. It's just like the courier-imap fiasco when baselayout-1.12 was touted for stable, but this time I Just Don't Care. There hasn't been any release of the mysql-init-scripts in 2 years. It's not that anything contrary to your opinions has been done on that bug, it's more that I haven't have any specific need to fix that package yet. Other than the need to actually allow mysql to work on Gentoo/FreeBSD. Ah, you've already said that you don't want to run anything other than Linux. Fine, that's your choice, but please hand mysql over to someone who cares about Gentoo running on alternative OS's as you've just demonstrated you just don't care. Thanks Roy
[gentoo-dev] Apache herds needs your help
Hi all, currently I am the only active developer in the apache herd, but quite busy with work and life, so I'd like to ask all of you to fix bugs assigned to apache-bugs@ if you come across them/if they annoy you etc, since i cannot keep up with bugs currently. I'd also like to see more active members in the herd as well in the future, so that bugs can be resolved in a reasonable time again. If you're interested, feel free to add yourself to herds.xml and join #gentoo-apache. Thanks, Bene pgpQdQmH0YBmh.pgp Description: PGP signature
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote: > 1. OpenRC will provide /libexec/rc/version, a text file containing the >version (possible including a git ID) of the release. that requires us to actually utilize /libexec/ which is not a Linux convention on any system ive ever seen. i dont think we should start for one package. i didnt see any problem with using /etc/openrc-release ? -mike signature.asc Description: This is a digitally signed message part.
