Re: [gentoo-portage-dev] Help with KDE Arts
Robert wrote: Hey, for some reason I cannot seem to install arts (KDE). Try asking that on the gentooo-user list, it has nothing to do with portage development. Marius -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] .53, .54 and beyond...
Hi all, I don't think there's really anything else that can be done for 2.0.53 so am thinking that we should probably push _rc7 + docs out and let the arch teams mark it stable when they're ready (or stick with 2.0.51.22-r3 if it pleaseth them). We should put out a 2.0.54_pre1 out soon after that. What I'm wondering in is what will be going in? So far I'm thinking along the lines of: * cache rewrite * exec cleanup * ldconfig fix * sha1 enabling The only other new thing in trunk that I know of is logging but there's still a question mark over the ordering of messages... Can that be resolved soon? Anything else missing? Any reasons against any of the above? What's on the map for after that? There's a few things listed on the new (still unreleased?) project index and I'm looking to get the dependency stuff refactored and moved out of emerge.. What are the shortterm goals? -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Saturday 26 November 2005 00:31, Ned Ludd wrote: On Sat, 2005-11-26 at 00:01 +0900, Jason Stubbs wrote: Hi all, I don't think there's really anything else that can be done for 2.0.53 so am thinking that we should probably push _rc7 + docs out and let the arch teams mark it stable when they're ready (or stick with 2.0.51.22-r3 if it pleaseth them). [snip] There's a few things listed on the new (still unreleased?) project index and I'm looking to get the dependency stuff refactored and moved out of emerge.. What are the shortterm goals? For me my short term goals are to see these things happen * pax-utils depends ( .53 ) * seeing CDEPEND stop being created for the VDB ( .53 ) Definitely doable. * post_sync action hook (.53/.54 ) * VDB prevention of single byte NULL entries being created. ( .54 ) Doable for .54. * new prepstrip offering splitdebug ( .53/.54 ) Need to work out exactly what will be offered when on this one, but at the earliest it will be .54. Perhaps go with your patch for .54 and leave Olivier's fancy bits for later? There are a few other questions too... Should the default be to generate external debug info? Should generating internal debug info still be offered? What platforms is it supported on?.. * misc cleanups of dyn_install (.54 ) Need more info. * flattened vdb {P,R,}DEPEND (.54 ) I might be wrong but I can't really see this being done cleanly. At best, only USE flags could be gotten rid of which would still leave || () constructs. This leads me to question of what use it would really be. If it can only do a half-arsed job and in a messy way at that I'd personally prefer it to be done later on. * introduction of RRDEPEND to the VDB ( .54 ) What is this again? -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote: On Saturday 26 November 2005 00:31, Ned Ludd wrote: On Sat, 2005-11-26 at 00:01 +0900, Jason Stubbs wrote: Hi all, I don't think there's really anything else that can be done for 2.0.53 so am thinking that we should probably push _rc7 + docs out and let the arch teams mark it stable when they're ready (or stick with 2.0.51.22-r3 if it pleaseth them). [snip] There's a few things listed on the new (still unreleased?) project index and I'm looking to get the dependency stuff refactored and moved out of emerge.. What are the shortterm goals? For me my short term goals are to see these things happen * pax-utils depends ( .53 ) * seeing CDEPEND stop being created for the VDB ( .53 ) Definitely doable. * post_sync action hook (.53/.54 ) * VDB prevention of single byte NULL entries being created. ( .54 ) Doable for .54. Yeah and from the sounds of it we may want more than 1 set of postsync hooks or the addition of a postsync.d/ (dev thread on getting vital info to users) * new prepstrip offering splitdebug ( .53/.54 ) Need to work out exactly what will be offered when on this one, but at the earliest it will be .54. Perhaps go with your patch for .54 and leave Olivier's fancy bits for later? I can only assure you the code I wrote will function properly. So that's the only thing I'm trying/willing to push myself. As long as he has those [ -x checks ] his code should be harmless, but I don't see the advantage in it over building with -g3. There are a few other questions too... Should the default be to generate external debug info? I think the security team would say yes they want it by default and would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo. I think ferringb would say make it FEATURES=splitdebug if it's going in midstream. It does add some size which would make peoples $ROOT's a little bit bigger. But from mine and other peoples testing it's pretty damn minimal. I think Halcy0n @ gentoo said after doing an -e world he ended up with only 18M of split debug info I'm also fond of split packaging of debug info also (but I'm not going to push for that till I find a more elegant way) [EMAIL PROTECTED] debug $ qsize pax-utils app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB Perhaps we should get input from gentoo-dev ml ? Should generating internal debug info still be offered? When FEATURES=nostrip is enabled we should not split off any debug info or touch the executable. What platforms is it supported on?.. Everywhere ELF is a standard. * misc cleanups of dyn_install (.54 ) Need more info. This is just something I want todo for my own sanity, ie break parts of our existing dyn_install() out into /usr/lib/portage/bin/ scripts. The current function is about 209 lines of code and I can see it growing even more. * flattened vdb {P,R,}DEPEND (.54 ) I might be wrong but I can't really see this being done cleanly. At best, only USE flags could be gotten rid of which would still leave || () constructs. This leads me to question of what use it would really be. If it can only do a half-arsed job and in a messy way at that I'd personally prefer it to be done later on. It will indeed still leave you with || ( foo bar ) or =cpv which you can be parsed just fine. Yeah it would be nice if it could be reduced more but later on or now I don't see how it can be reduced anymore than to the requirements that the ebuild requested. One big advantage for me here is that virtuals would be resolved. This will probably lead to an overall reduction in size of the VDB. * introduction of RRDEPEND to the VDB ( .54 ) What is this again? Ok I talked a little bit about this on this list the other day and a few months ago with you on #-portage. man RRDEPEND This entry is automatically created by portage. It contains a list of reverse dependencies that is achieved by resolving the DT_NEEDED entries of an ELF executable. /man Justification Programs such as revdep-rebuild, verify-rdepend would be able to make immediate use. A little bit of a longer term goal is to see portage gain the ability to request to only use RRDEPEND entries to be used for depgraph creation for use with embedded/mimimal systems. ROOT=/dev/shm/minimal emerge -KO --deps=RRDEPEND pkgfoo RRDEPEND will need to exist due to the RDEPEND explosion and lack of a clear definition when it was first introduced to portage. The advantage from where I'm sitting is that devs don't really have a chance to make mistakes with R/DEPEND handling and people who are attempting to stage $ROOT can get exactly what they are after in the embedded world. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 21:00 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 12:05:57 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Programs such as revdep-rebuild, verify-rdepend would be able to make | immediate use. A little bit of a longer term goal is to see portage | gain the ability to request to only use RRDEPEND entries to be used | for depgraph creation for use with embedded/mimimal systems. How will that work for packages that have a runtime dependency upon a text file supplied by a different package? text files which are true runtime deps belong in RDEPEND. Clearly c++ templates are beyond the scope of the what RRDEPEND can provide. I could be wrong but I don't think those c++ templates are anything revdep-rebuild or verify-rdepends handle any differently. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
[ Apologies if two of these show up. I kinda, uh, broke Exim slightly... ] On Fri, 25 Nov 2005 16:41:19 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | On Fri, 2005-11-25 at 21:00 +, Ciaran McCreesh wrote: | How will that work for packages that have a runtime dependency upon | a text file supplied by a different package? | | text files which are true runtime deps belong in RDEPEND. So an embedded system creating tool thing will end up providing broken installs when ignoring RDEPEND? | Clearly c++ templates are beyond the scope of the what RRDEPEND can | provide. I could be wrong but I don't think those c++ templates are | anything revdep-rebuild or verify-rdepends handle any differently. Separate issue. I was thinking more along the lines of (non-minimal) vim needing vim-core, for example. -- Ciaran McCreesh : Gentoo Developer (Supreme Lord Gerbil Wrangler) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 22:02 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 16:41:19 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | On Fri, 2005-11-25 at 21:00 +, Ciaran McCreesh wrote: | How will that work for packages that have a runtime dependency upon | a text file supplied by a different package? | | text files which are true runtime deps belong in RDEPEND. Ok. So embedded tools which rely upon RRDEPEND for runtime dependencies will end up producing incomplete installs? Yeah that's what we want, We intend to create tools that leave systems broken. You want to be the first tester? Please take your spin of things off of this and look at it for what it is. Your not going to use a feature for something unless it's suited for the job at hand. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 25 Nov 2005 17:49:50 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Yeah that's what we want, We intend to create tools that leave systems | broken. You want to be the first tester? Please take your spin of | things off of this and look at it for what it is. Your not going to | use a feature for something unless it's suited for the job at hand. So why not create a better feature? -- Ciaran McCreesh : Gentoo Developer (Supreme Lord Gerbil Wrangler) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 23:10 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 17:49:50 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Yeah that's what we want, We intend to create tools that leave systems | broken. You want to be the first tester? Please take your spin of | things off of this and look at it for what it is. Your not going to | use a feature for something unless it's suited for the job at hand. So why not create a better feature? What the hell are you talking about? No tools have even been created yet. Nobody builds tools before the framework is in place. The ability to make use of RRDEPEND as I've pointed out by verify-rdepend and revdep-rebuild could be pretty much immediate. The ability to control what level of depends a user wants in his/her depgraph is up to the user. The way I envision it you could just as easliy do ROOT=/dev/shm/minimal emerge -KO --deps=RDEPEND:DEPEND:PDEPEND pkgfoo To yield the same results as portage by default. In general I'd suggest that you not attempt to make use of features that don't suit your needs. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 23:53 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 18:48:41 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | What the hell are you talking about? No tools have even been | created yet. Nobody builds tools before the framework is in place. The | ability to make use of RRDEPEND as I've pointed out by verify-rdepend | and revdep-rebuild could be pretty much immediate. The ability to | control what level of depends a user wants in his/her depgraph is up | to the user. The way I envision it you could just as easliy do | ROOT=/dev/shm/minimal emerge -KO --deps=RDEPEND:DEPEND:PDEPEND | pkgfoo To yield the same results as portage by default. In general | I'd suggest that you not attempt to make use of features that don't | suit your needs. Why introduce a feature which is crippled? It would be almost as easy to allow ebuilds to mess with their 'real' runtime dependency value as appropriate rather than forcing an incorrect auto-generated list onto everyone. Please go back to trolling on dev We are trying to get work done here and solve real problems. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 25 Nov 2005 19:00:07 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Why introduce a feature which is crippled? It would be almost as | easy to allow ebuilds to mess with their 'real' runtime dependency | value as appropriate rather than forcing an incorrect | auto-generated list onto everyone. | | Please go back to trolling on dev We are trying to get work done here | and solve real problems. Sure. You're inventing some arbitrary problem which has no reflection upon reality and then solving some other arbitrary problem which has no reflection upon either reality or what you say you're solving. End result is more unnecessary complexity, more unnecessary mess and, once you realise your solution is inadequate, no doubt yet another incomplete hack on top of that. -- Ciaran McCreesh : Gentoo Developer (Supreme Lord Gerbil Wrangler) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: Bugzilla Bug 112779: New and Improved Way to Handle /etc/portage
On Thu, 17 Nov 2005 09:30:15 +0200 Marius Mauch [EMAIL PROTECTED] wrote: Anthony Gorecki wrote: On Wednesday, November 16, 2005 23:12, Zac Medico wrote: I wouldn't mind having a feature like this. I would provide a way for automatic unmasking tools to keep their changes separate and easily reversible. This seems to be borderlining on being unnecessary, in my opinion. A commented section in package.unmask could work just as easily, and it would likely save time for the user. kde-base/kdelibs is just as easy to find in a sorted, sectioned file as it is in multiple files: # GNOME Packages: [...] # KDE Packages: [...] I think the point is more with a) temporary enabling/disabling of sections and b) sharing sections. Having multiple files those situations are a bit easier to handle. Shouldn't be too hard offhand, basically if isdir(foo): for x in listdir(foo): mylines.extend(grabfile(x)) else: mylines = grabfile(foo) Ok, patch is now available at dev.gentoo.org/~genone/patches/portage-recursive-grab+config.diff 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
Re: [gentoo-portage-dev] .53, .54 and beyond...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 25 Nov 2005 19:00:07 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Why introduce a feature which is crippled? It would be almost as | easy to allow ebuilds to mess with their 'real' runtime dependency | value as appropriate rather than forcing an incorrect | auto-generated list onto everyone. Talking on solar about this confirmed my suspicions, the ELF data can't be wrong, otherwise things won't link properly. Thus if we were just to use ELF NEEDED entries, how could the list of reverse runtime deps be incorrect as you imply above? The only assumption here is that ELF is supported on that platform/arch. | | Please go back to trolling on dev We are trying to get work done here | and solve real problems. Sure. You're inventing some arbitrary problem which has no reflection upon reality and then solving some other arbitrary problem which has no reflection upon either reality or what you say you're solving. End result is more unnecessary complexity, more unnecessary mess and, once you realise your solution is inadequate, no doubt yet another incomplete hack on top of that. So in regards to reverse dependency tracking, do you have a solution/advice or just useless criticism? Please attempt to be constructive here. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ4evCWzglR5RwbyYAQKXlw//YqvAsDkbt3PYmCII6LELOs5qEo8iUPI9 IZuauacBt6uqoVY7UyP36Wt2ky9rqnO2fFlON6i39MjdfN3XsyVIRqVwf4agwWFM QuH19h3wQfCsum5vMKZMej8qfskdpozj4VeTeU2f/NxS6g19LW8vzH7MTDY13tr3 bmY1unyQK7rx6bN+qtV/l22Doq4WnFBDWrY68L00wqHBGzn/VNl9Gh6JTVMTO/AL +yEMma4b0+feCcfrSyxgiliSnaZS+ghJyLPyY4P/gVxDlOP577ufzKxPHgaOh9FN hGaiSaS69Xf4XMcawcdmsE/Tp9Kp1uWXfJibaDCSw4xlmRwm7J26s97NaBu6YsWh keJ1nnMl1O9fjuVCiERVJGMQCYJNAP7up+YAwC62FwNqJSOk5PMS8jz/+uPbWwSW FRTZZCxTDe6JSbZ1RAPLY8xzQFtfdeU4T/wEiWj61w8yRqV132bHiay/lsVNq6P9 GWCvU7pphfe7cNDlk1cHT8eQOE91bVfmKdZBZ+eUgPQk6esMuMCh1MIj38s1lJOi XGxIe3pECS7NPinv8n9ujaYoY7y7Uw+AQTbfFJjdRyldfciqbOpjiv4DfwgVIeiN BE3bio08ybIT7Hb1g9GwPIkycbTbpT4JlBgAKrH3BIBs1d2Syae8DOR3P6WlJDZ/ lD1dIhX5JQ8= =GkJo -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 25 Nov 2005 19:42:14 -0500 Alec Warner [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Fri, 25 Nov 2005 19:00:07 -0500 Ned Ludd [EMAIL PROTECTED] | wrote: | | Why introduce a feature which is crippled? It would be almost as | | easy to allow ebuilds to mess with their 'real' runtime | | dependency value as appropriate rather than forcing an incorrect | | auto-generated list onto everyone. | | Talking on solar about this confirmed my suspicions, the ELF data | can't be wrong, otherwise things won't link properly. Thus if we were | just to use ELF NEEDED entries, how could the list of reverse runtime | deps be incorrect as you imply above? It can be incomplete. Of course, finding the ELF NEEDED entries is not a sufficient solution to the initial problem, nor is it a sufficient solution to the real problem here. | So in regards to reverse dependency tracking, do you have a | solution/advice or just useless criticism? Please attempt to be | constructive here. Sure. My advice is to scrap the current idea and redo it to take into account things which are not just ELF-related. -- Ciaran McCreesh : Gentoo Developer (The one that looks before leaping) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] .53, .54 and beyond...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 25 Nov 2005 19:42:14 -0500 Alec Warner [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Fri, 25 Nov 2005 19:00:07 -0500 Ned Ludd [EMAIL PROTECTED] | wrote: | | Why introduce a feature which is crippled? It would be almost as | | easy to allow ebuilds to mess with their 'real' runtime | | dependency value as appropriate rather than forcing an incorrect | | auto-generated list onto everyone. | | Talking on solar about this confirmed my suspicions, the ELF data | can't be wrong, otherwise things won't link properly. Thus if we were | just to use ELF NEEDED entries, how could the list of reverse runtime | deps be incorrect as you imply above? It can be incomplete. Of course, finding the ELF NEEDED entries is not a sufficient solution to the initial problem, nor is it a sufficient solution to the real problem here. Well I bought this bug-spray and it only kills 99% of the bugs in my home, so I guess I should scrap it and work on something better that kills 100% of bugs? If this helps stem system breakage by repairing a number of broken library deps, how is that bad? Because it doesn't adhere to Ciaran's ideal feature standards? | So in regards to reverse dependency tracking, do you have a | solution/advice or just useless criticism? Please attempt to be | constructive here. Sure. My advice is to scrap the current idea and redo it to take into account things which are not just ELF-related. Bricklayers build walls, one brick at a time. - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ4e5yGzglR5RwbyYAQJJWQ/+KdAbQKfUg6HWzzrNRlMJWjKau+PLuW6x gvT/vRU6lYz6612lVbrAmXxir0UdkYjZIe5AXXEz+bTg9K78xL0HuvBb2/fyYihy +pAhkpOhI5eE7dc8fn5vV1dIEOtnBco+UZakSfi9Eai4+PqmaLWwOtiyMnNw3veM yby6Pm/H0VXVzJS5aVQXdPI4PDyyRO3dbLrbuMR9BOPn/qDsZIaB+A+Loy3TajKY BVPsPicGG1OsTnEL8YCgQ4Tl03aepLVuQDomV5vIje4rKfk80fi5UjhMCdHRzFrR Ej2cyyTexQqfNK2IXGh/0R0vgeJCfyMLhCK6b9PkVLSPfv38sJPxWOZuyBd5t8Qu jzJIz0Fhqqg1spfo9rOeFyuW/oOe86hGmFqj+QCrnGhKG0kmyzWeC4IFXClk1PJz P5Kt65uOJU8xOUUZKiUrQ+BnmK0KEYW0InBHmSCCGIjbwC9QCII9gLFlzwqzEd+8 xmnisEa2O5qiX0dSgQoUkenZR9ZvMAWYXkwa9REPiI2uappcagADDL6rR4YIRCOX E96sTByTji7fqu1FsOuARIasdp1PvGoxOr2M5dxoPV/ENcZG0X+NHaw6eUqq13dT ed30XQq/nYxTUcxDKAsWEpOMfMIkzlqxnIL6mN5rjoUZLXnQYDhCJlC3QCmS3uGW eH6ypTlY/9s= =gApf -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 26 Nov 2005 00:01:15 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: Hi all, I don't think there's really anything else that can be done for 2.0.53 so am thinking that we should probably push _rc7 + docs out and let the arch teams mark it stable when they're ready (or stick with 2.0.51.22-r3 if it pleaseth them). We should put out a 2.0.54_pre1 out soon after that. What I'm wondering in is what will be going in? So far I'm thinking along the lines of: * cache rewrite * exec cleanup * ldconfig fix * sha1 enabling The only other new thing in trunk that I know of is logging but there's still a question mark over the ordering of messages... Can that be resolved soon? Anything else missing? Any reasons against any of the above? Resolved how? I'm not really sure I understood the original problem (other than listdir being underdeterministic in theory). What's on the map for after that? There's a few things listed on the new (still unreleased?) project index and I'm looking to get the dependency stuff refactored and moved out of emerge.. What are the shortterm goals? - the pycrypto hash additions (for .54) - Manifest2 verification support (need the GLEP first so the format is sanctioned). Technically it's complete, just generation is still unfinished. (so a maybe for .54 depending on the timeframe) - Killing off auto-use+USE_ORDER? - the recursive grab* functions I just posted (for .54) - addition of auxget/metascan tools (could be for .54) - integration of set modules, either as emerge targets (requires serious gutting of emerge) or a first-class atoms (semantically tricky, no clue about implementation yet) 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
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Saturday 26 November 2005 11:07, Marius Mauch wrote: On Sat, 26 Nov 2005 00:01:15 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: The only other new thing in trunk that I know of is logging but there's still a question mark over the ordering of messages... Can that be resolved soon? Anything else missing? Any reasons against any of the above? Resolved how? I'm not really sure I understood the original problem (other than listdir being underdeterministic in theory). TGL suggested that all the messages go into a single file with some sort of prefix that would then be parsed on the python side. The original order of messages could then be maintained. However, seeing as there needs to be no compatibility with the temporary files it could wait for later anyway. What's on the map for after that? There's a few things listed on the new (still unreleased?) project index and I'm looking to get the dependency stuff refactored and moved out of emerge.. What are the shortterm goals? - the pycrypto hash additions (for .54) This is only useful if the vote goes in favour of adding further hash types to Manfiest, right? If the vote goes that way I've got no issues with it, but if it doesn't it would essentially be dead code. - Manifest2 verification support (need the GLEP first so the format is sanctioned). Technically it's complete, just generation is still unfinished. (so a maybe for .54 depending on the timeframe) Again, depends on -dev. - Killing off auto-use+USE_ORDER? Yep, I'd really like to see this one gone too. We should probably state the intention on -dev first though as there might be a lot of people against it. - the recursive grab* functions I just posted (for .54) Needs a small amount of work (/etc/portage/package.mask/foo/bar would break it) but I like the general idea. - addition of auxget/metascan tools (could be for .54) No qualms. - integration of set modules, either as emerge targets (requires serious gutting of emerge) or a first-class atoms (semantically tricky, no clue about implementation yet) I'm working on this with my refactoring. Defininately a post-.54 thing unless you want to quickly hack it into getlist()? -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Saturday 26 November 2005 02:05, Ned Ludd wrote: On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote: On Saturday 26 November 2005 00:31, Ned Ludd wrote: * post_sync action hook (.53/.54 ) * VDB prevention of single byte NULL entries being created. ( .54 ) Doable for .54. Yeah and from the sounds of it we may want more than 1 set of postsync hooks or the addition of a postsync.d/ (dev thread on getting vital info to users) Heh.. that was my suggestion. ;) * new prepstrip offering splitdebug ( .53/.54 ) Need to work out exactly what will be offered when on this one, but at the earliest it will be .54. Perhaps go with your patch for .54 and leave Olivier's fancy bits for later? I can only assure you the code I wrote will function properly. So that's the only thing I'm trying/willing to push myself. As long as he has those [ -x checks ] his code should be harmless, but I don't see the advantage in it over building with -g3. There are a few other questions too... Should the default be to generate external debug info? I think the security team would say yes they want it by default and would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo. I think ferringb would say make it FEATURES=splitdebug if it's going in midstream. It does add some size which would make peoples $ROOT's a little bit bigger. But from mine and other peoples testing it's pretty damn minimal. I think Halcy0n @ gentoo said after doing an -e world he ended up with only 18M of split debug info I'm also fond of split packaging of debug info also (but I'm not going to push for that till I find a more elegant way) [EMAIL PROTECTED] debug $ qsize pax-utils app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB Perhaps we should get input from gentoo-dev ml ? Sounds good for pretty much all aspects of split debug (other than the capability itself). Should generating internal debug info still be offered? When FEATURES=nostrip is enabled we should not split off any debug info or touch the executable. FEATURES=splitdebug|stripdebug and do nothing if neither is set? * misc cleanups of dyn_install (.54 ) Need more info. This is just something I want todo for my own sanity, ie break parts of our existing dyn_install() out into /usr/lib/portage/bin/ scripts. The current function is about 209 lines of code and I can see it growing even more. Code cleanups are always good. :) * flattened vdb {P,R,}DEPEND (.54 ) I might be wrong but I can't really see this being done cleanly. At best, only USE flags could be gotten rid of which would still leave || () constructs. This leads me to question of what use it would really be. If it can only do a half-arsed job and in a messy way at that I'd personally prefer it to be done later on. It will indeed still leave you with || ( foo bar ) or =cpv which you can be parsed just fine. Yeah it would be nice if it could be reduced more but later on or now I don't see how it can be reduced anymore than to the requirements that the ebuild requested. Again, if it can be done cleanly code-wise no issues with resolving the USE flags out. One big advantage for me here is that virtuals would be resolved. Resolving virtuals can't be done. Virtuals are meant to be binary compatible with each other which means that they can be replaced by each other interchangeably. However, once portage starts using info from vdb (soon) and starts doing proper sanity checking (not so soon) one would need to re-emerge all reverse dependencies in order to switch installed virtual provider. * introduction of RRDEPEND to the VDB ( .54 ) What is this again? Ok I talked a little bit about this on this list the other day and a few months ago with you on #-portage. man RRDEPEND This entry is automatically created by portage. It contains a list of reverse dependencies that is achieved by resolving the DT_NEEDED entries of an ELF executable. /man Justification Programs such as revdep-rebuild, verify-rdepend would be able to make immediate use. Yes, but an extension to emaint will be needed to create the files for existing installed packages. I'm not sure that Brian's plugin architecture is ready for .54 so it would need to be another hardcoded check/fix into emaint itself. Not sure I really like that idea but I'm not going to fight if the majority think that it should go into .54... What do the majority think? A little bit of a longer term goal is to see portage gain the ability to request to only use RRDEPEND entries to be used for depgraph creation for use with embedded/mimimal systems. ROOT=/dev/shm/minimal emerge -KO --deps=RRDEPEND pkgfoo RRDEPEND will need to exist due to the RDEPEND explosion and lack of a clear definition when it was first introduced to portage. The advantage from where I'm sitting is that
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote: [snip stuff] Need to head to bed now. Will respond to other parts tomorrow. A little bit of a longer term goal is to see portage gain the ability to request to only use RRDEPEND entries to be used for depgraph creation for use with embedded/mimimal systems. ROOT=/dev/shm/minimal emerge -KO --deps=RRDEPEND pkgfoo This is definitely not something that could be done in any of 2.x unless it's done as an external tool (which would not be so hard as order doesn't matter with binary packages). I'm not sure that I like the idea of selectively ignoring *DEPEND in 3.x anyway - by that stage sanity checking should be 100% but selective *DEPENDs will either poke huge holes through it or make a huge mess. Either way, it's not a tomorrow thing so discussion should probably wait until it's more viable. That's fine I'm not ready to focus on --deps= right away. As stated it's a longer term goal and I would also prefer to discuss it at a later time. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list