| 1 |
Looks like my first mail disappeared somehow, lets try again: |
| 2 |
|
| 3 |
On Sat, 14 Jun 2008 22:55:23 -0500 |
| 4 |
"Lucian Poston" <lucianposton@×××××.com> wrote: |
| 5 |
|
| 6 |
> I put the new RevdepSet module in a separate file. Should I instead |
| 7 |
> include this in one of the existing files? I couldn't find a clear |
| 8 |
> description of the purpose of the set classes within each file, so I |
| 9 |
> simply placed it in a new one. Also, did anyone have a more succinct, |
| 10 |
> descriptive name suggestion for the set already in mind? |
| 11 |
|
| 12 |
For the purpose of SoC it's better to keep it in a separate file, |
| 13 |
though for deployment it's probably going to be integrated into |
| 14 |
sets/libs.py. As for name, the old prototype was named |
| 15 |
MissingLibraryConsumerSet (mainly due to inheriting from |
| 16 |
LibraryConsumerSet, which you might also be interested in). |
| 17 |
|
| 18 |
> My plan over the next few days is to build a list of "needed" |
| 19 |
> libraries (either through dbapi or my own implementation similar to |
| 20 |
> linkmap), a list of installed libraries (I'm still unsure of the best |
| 21 |
> way to build this list. Simply searching through lib directories |
| 22 |
> perhaps?), and comparing the two lists to find which are missing. The |
| 23 |
> packages are already associated with the libraries in var/db/pkg, so |
| 24 |
> that shouldn't be a problem. I'll see how that works and go from |
| 25 |
> there. |
| 26 |
|
| 27 |
Sounds like a job for linkmap.findProviders(), but might be an idea to |
| 28 |
implement multiple solutions for comparison/testing purposes |
| 29 |
(see sets/security.py for one way to do that). |
| 30 |
|
| 31 |
> Are there any future plans to integrate the concept of recompiling |
| 32 |
> necessary binaries against newly updated libraries when upgrading |
| 33 |
> through emerge? Or is it more likely to stay as is with preserved-lib |
| 34 |
> functionality? I was just wondering about the futility of this whole |
| 35 |
> project in the future. :) |
| 36 |
|
| 37 |
Well, the only thing I'm somewhat planning atm is to (optionally) |
| 38 |
automatically rebuild certain sets after an emerge session, but that's |
| 39 |
just a plan for now and definitely won't happen before SoC is over. |
| 40 |
Other than that we'll have to see how preserve-libs works out in |
| 41 |
practice, but I don't expect it to go away that soon. |
| 42 |
Btw, if you're worried that preserve-libs makes your project redundant, |
| 43 |
it won't. It is supposed to reduce the need for it, but as it's |
| 44 |
optional and only limited in scope there will always be a need for |
| 45 |
revdep-rebuild functionality. |
| 46 |
|
| 47 |
> Should emerge revdep-rebuild rebuild the packages that are compiled |
| 48 |
> against preserved libraries? I assume no, since that functionality is |
| 49 |
> already present with preserved-libs, but I wanted to be sure. |
| 50 |
|
| 51 |
Better to not include preserved libs. Would be trivial to create a |
| 52 |
wrapper set to include both individual sets if necessary. |
| 53 |
|
| 54 |
Marius |
| 55 |
|
| 56 |
-- |
| 57 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 58 |
|
| 59 |
In the beginning, there was nothing. And God said, 'Let there be |
| 60 |
Light.' And there was still nothing, but you could see a bit better. |
| 61 |
-- |
| 62 |
gentoo-soc@l.g.o mailing list |
Archives