Re: [gentoo-dev] OpenRC & baselayout-2 meets Gentoo
Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module "openrc". I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. The installation handbooks won't be changed until openrc & baselayout-2 are stabilized and shipped with the stage3 tarballs. The same goes for our existing documentation. Until the new baselayout & openrc are stabilized, made the default, *and* the old stuff is marked deprecated, don't expect it to show up in our other documents alongside baselayout-1 content. The last thing I want is to fork our documentation code samples, and duplicate everything with "if you're on baselayout2 and/or openrc, do this instead" instructions. That type of thing is a maintenance and usability headache. It's all or nothing. "There can be only one!" I'll be working on the migration guide with Cardoe (and possibly Roy, if we can tag-team him into submission). As much of a pain as migration will be, we'll definitely need a howto. Fun, fun. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: RFC: New build types
Rémi Cardona wrote: > Steve Long a écrit : >> First and foremost to give an environment wherein people can write their >> installation scripts using the language they are most comfortable with. > > If bash is not "easy" or straightforward enough for what you are trying > to achieve, then I'd say the package is broken (ie, hand-made configure > script, odd makefiles and whatnot). Better fix the package rather than > rewriting ebuilds, make the world a better place. > Heh, I'm fine with BASH believe it or not ;p nor do I have that much interest in the other scripting languages. I really just think it would make porting stuff to Gentoo a lot simpler for people who don't know Cbut do know their language of choice. >> Secondly efficiency; in the case of a pbuild it could be run from within >> the PM; for something like a jbuild it would use the native tools and >> existing libraries like ANT. For hbuild it would tie into Cabal. While >> these may be used already, we go from PM -> BASH -> LangX. I'm just >> saying give the _option_ to leave out the BASH bit when you have mature >> tools in langX. > > Care to back that up with any sort of figure or number? Is bash really > the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the > bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. > > But then again, I don't have any numbers to back that up either... > I don't have figures, but my understanding is that one of the major factors in pkgcore's speed (which *is* impressive, even if the UI isn't quite there yet) is that it doesn't reload bash for every phase. (The whole ebuild "daemon" or ebd thing.) > Honestly, maybe it could be a fun project, but I'm hardly convinced it > would bring any sort of real advantage to the tree. In fact, having > ebuilds in many languages would probably wreak havoc more than anything > else. > I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. It's something I'd imagine would be used only for packages developed in the relevant overlay, since that's where the people who know the language develop stuff (and they'd be the ones maintaining their version.) However, they'd need to know that, once they've signed off on it, the central tree will support it without further code changes. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: New build types
On Thu, 20 Mar 2008 03:59:01 + Steve Long <[EMAIL PROTECTED]> wrote: > Rémi Cardona wrote: > > > What would be the point of such a change? What problem are you > > trying to solve or to improve? > > > Secondly efficiency; in the case of a pbuild it could be run from > within the PM; for something like a jbuild it would use the native > tools and existing libraries like ANT. For hbuild it would tie into > Cabal. While these may be used already, we go from PM -> BASH -> > LangX. I'm just saying give the _option_ to leave out the BASH bit > when you have mature tools in langX. Generally those build tools are designed to be invoked from the shell, not from within their implementation language. Of course you can invoke use a distutils setup.py script from within a python interpreter, but that's not how it's designed to be used and will probably end up being more complicated to handle than invoking it from the shell. Maybe it's 1% or 2% faster, but that's not worth the additional complexity. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] OpenRC & baselayout-2 meets Gentoo
All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module "openrc". I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: New build types
Steve Long a écrit : First and foremost to give an environment wherein people can write their installation scripts using the language they are most comfortable with. If bash is not "easy" or straightforward enough for what you are trying to achieve, then I'd say the package is broken (ie, hand-made configure script, odd makefiles and whatnot). Better fix the package rather than rewriting ebuilds, make the world a better place. Secondly efficiency; in the case of a pbuild it could be run from within the PM; for something like a jbuild it would use the native tools and existing libraries like ANT. For hbuild it would tie into Cabal. While these may be used already, we go from PM -> BASH -> LangX. I'm just saying give the _option_ to leave out the BASH bit when you have mature tools in langX. Care to back that up with any sort of figure or number? Is bash really the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. But then again, I don't have any numbers to back that up either... Honestly, maybe it could be a fun project, but I'm hardly convinced it would bring any sort of real advantage to the tree. In fact, having ebuilds in many languages would probably wreak havoc more than anything else. My 2¢ Cheers, Rémi -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Help offered - Portage tree
> Come on lxnay, who are you trying to fool here? Oh for crying out loud, Pierre. How paranoid! Luca - questioning Gentoo's HR shouldn't elicit insults about pigs and trolls. This behavior suggests you are too easy to piss off in the first place. I'm not going to bother with pointwise pseudo-rebuttals that amount to not listening. I am an experienced developer. The proof is in the pudding. If Gentoo gains more devs than it loses, and the bugzilla shrinks faster than it grows, then I will change my mind. Anyway you're clearly set in your ways! Good luck! Dave -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: New build types
Luca Barbato wrote: > Steve Long wrote: >> Something that's been discussed on IRC is the idea of a .pbuild file, >> written in Python. I can also think of .cbuild (C) .Cbuild (C++) .sbuild >> (Scheme) .hbuild (Haskell) and .jbuild (guess;) as being of immediate >> use, (although I accept I might be the only one interested in the first >> ;) > > I do not see any improvement per se. > Well I agree C and C++ aren't very useful, since they are more than adequately covered by make et al. With the others, there are setup tools like distutils in the language already. >> How do others feel about such an addition? > > I think it's pointless. > Fair enough. It's intended to make it easier to write install scripts. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Remaining PMS todo list etc
On Wed, 19 Mar 2008 18:32:41 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > There's an updated, pre-built copy of current PMS at: > > > > http://dev.gentoo.org/~spb/pms.pdf > > Thanks for keeping up with this. > > > * 174335: Some ebuild use FEATURES. Can we get them to stop doing > > that, or do we have to force package managers to emulate it? > > We seriously need a PM-independent way of saying "run the testsuite", > "run the testsuite with user privledges", and "run the testsuite with > root privledges if you can, otherwise forget it". Also required is > the ability to make test failures non-fatal on a per-package basis, > though this probably has nothing to do with the PMS. How about just checking EUID == 0 in src_test and skip the tests (with a ewarn message) if it doesn't match your needs? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: New build types
Rémi Cardona wrote: > What would be the point of such a change? What problem are you trying to > solve or to improve? > First and foremost to give an environment wherein people can write their installation scripts using the language they are most comfortable with. Secondly efficiency; in the case of a pbuild it could be run from within the PM; for something like a jbuild it would use the native tools and existing libraries like ANT. For hbuild it would tie into Cabal. While these may be used already, we go from PM -> BASH -> LangX. I'm just saying give the _option_ to leave out the BASH bit when you have mature tools in langX. > You'll need to answer those questions anyway should you ever need to > write a GLEP for that. > Yeah, that's a long way off; no point doing a GLEP without a working implementation to show what you mean, imo. No point dedicating coder resource to implement if it'd never get used in any case. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Remaining PMS todo list etc
Ciaran McCreesh wrote: There's an updated, pre-built copy of current PMS at: http://dev.gentoo.org/~spb/pms.pdf Thanks for keeping up with this. * 174335: Some ebuild use FEATURES. Can we get them to stop doing that, or do we have to force package managers to emulate it? We seriously need a PM-independent way of saying "run the testsuite", "run the testsuite with user privledges", and "run the testsuite with root privledges if you can, otherwise forget it". Also required is the ability to make test failures non-fatal on a per-package basis, though this probably has nothing to do with the PMS. -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Remaining PMS todo list etc
There's an updated, pre-built copy of current PMS at: http://dev.gentoo.org/~spb/pms.pdf And source at: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git And "PMS for people who haven't been paying attention" at: http://archives.gentoo.org/gentoo-dev/msg_4ac035019b5264e5b9c176493bcc6b5b.xml And an explanation of kdebuild at: http://archives.gentoo.org/gentoo-dev/msg_0594dd89e411526c2a68cae9916c6a16.xml And the following note about bugs: Please stop making bugs with [EAPI-2] or whatever in the title. Use [Future EAPI] unless you have a definite agreement from absolutely everybody and their dog that it's going into EAPI 2. I had to go through and fix a load of bugs saying [EAPI 1] and don't really want to do it again. Things still left to do for PMS are as follows. Well-informed people are encouraged to comment and provide patches to [EMAIL PROTECTED] If you aren't sure whether you're well-informed, you aren't. * Someone needs to write up dohtml. * 178092: Someone needs to write up package.use. * 170697: can we consider profile masks to be in the same category as 'use? ( ) : ( )' and thus not worth documenting? * 174319: make.defaults needs to be parsed by things other than bash. Just how much of bash's syntax do we support? * 174330: PMS currently bans interactivity except in pkg_config. * 174335: Some ebuild use FEATURES. Can we get them to stop doing that, or do we have to force package managers to emulate it? * 174536: Currently there's no way to tell whether you have a cat/pkg or a cat/pkg-ver, and in no place does anything have to do so. Do we want to introduce new restrictions so that people can do that? * 175246: Portage sets EBUILD_PHASE=depend for the metadata source. Do we want to enforce this? * 188449: The eight digit limit for version parts is still in. Do we want to keep it? * 196561: PMS describes the ~ operator as working the way developers expect it to work, but Portage doesn't quite do that. * 202631: PMS doesn't document profile.bashrc. Currently, Paludis ignores it because most of the code that ends up there is extremely Portage specific. Do we document profile.bashrc and make it much more constrained? -- Ciaran McCreesh signature.asc Description: PGP signature
