[gobolinux-users] exclude localrecipes from freshen and friends?

[kenneth marken]

On Thursday 22 May 2008 00:52:53 Michael Homer wrote:
> On Thu, May 22, 2008 at 9:41 AM, kenneth marken <k-marken at online.no> wrote:
> > i find myself at times with long forgotten failed attempts at getting
> > some compile or other going in localrecipes. these often make their ways
> > into compile or freshen, making it seem as if there is a more recent
> > version available then there really is.
>
> /etc/Compile/Compile.conf
>

ugh, i looked inside there and didnt find anything. but now i see the 
compileRecipeDirs entry. im guessing that putting a # at the line about 
LocalRecipes should do the trick?

> > also, some more filtering of freshen output could be nice. i tried using
> > grep but i gave me all or nothing. i guess it got confused over the
> > colors or something.
>
> grep works fine, but you can use --no-colour to disable the colouring
> if you prefer (seems to be undocumented, I will fix that). Otherwise,
> please elaborate.
>

well i tried to get it to show only packages by doing a grep on the [ P], but 
i could not find a regex that worked (unless i messed up how to tell grep 
that it should read the [ as just that, not some regex part).

> > oh, and i found that freshen points a lot of "want to install" (those
> > white ones that there are no current installed version of) to
> > gtk-qt-engine, when the real source of them are kde-libs 4.0.4.
>
> It's *one* program that is pulling it into the tree. It is any
> arbitrary parent, chosen essentially randomly (to be precise, it's
> whichever n-parent of the dependency has the lowest Python string hash
> value modulo some number greater than the number of updateable
> programs on your system - i.e. whichever one comes first in the
> iteration of a set). It isn't necessarily a direct parent, just
> something that is causing the new dependency to be pulled in.
>

ah, so it just shows the top of the "tree".

> > if possible, how about a tree sort of the freshen output? but i guess it
> > would make the current freshen even slower then it already is thanks to
> > it trying to at least do some level of sorting, right?
>
> It is already sorted.
>

yep, but i cant seem to figure out what the basis for the sorting is. as in, 
what source of data makes something be sorted towards the top or bottom, or 
how are the different packages and recipes related.

right now all i can do is tunnel down using repeated freshen requests on a app 
or lib, and see what is reported as dependent.

still, i can see potential problems when more then one recipe wants something 
like gcc or qt.

> SVN Freshen is much faster, around 90% (!), due to some
> CheckDependencies fixes I made. You also need SVN Scripts, which are
> pretty stable right now. Freshen -C now runs me about thirty seconds
> with 250 updates. You might like to try that, it is much more pleasant
> to use.

i think ill manage until a official release. but nice to know :D

also i guess it will remove one of the main issues with having to do repeated 
freshens to get a sense of the dependence tree of a recipe or package ;)

or maybe im abusing freshen in ways it was not intended to be used?