Re: [gentoo-portage-dev] Help with KDE Arts

2005-11-25 Thread Marius Mauch

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...

2005-11-25 Thread Jason Stubbs
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...

2005-11-25 Thread Jason Stubbs
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...

2005-11-25 Thread Ned Ludd
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...

2005-11-25 Thread Ned Ludd
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...

2005-11-25 Thread Ciaran McCreesh
[ 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...

2005-11-25 Thread Ned Ludd
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...

2005-11-25 Thread Ciaran McCreesh
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...

2005-11-25 Thread Ned Ludd
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...

2005-11-25 Thread Ned Ludd
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...

2005-11-25 Thread Ciaran McCreesh
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

2005-11-25 Thread Marius Mauch
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...

2005-11-25 Thread Alec Warner
-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...

2005-11-25 Thread Ciaran McCreesh
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...

2005-11-25 Thread Alec Warner
-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...

2005-11-25 Thread Marius Mauch
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...

2005-11-25 Thread Jason Stubbs
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...

2005-11-25 Thread Jason Stubbs
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...

2005-11-25 Thread Ned Ludd
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