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

[kenneth marken]

On Thursday 22 May 2008 02:42:15 Michael Homer wrote:
> On Thu, May 22, 2008 at 11:42 AM, kenneth marken <k-marken at online.no> wrote:
> > 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?
>
> Yes.
>
> >> > 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).
>
> The colours will mess with that, as will grep - you have to escape any
> regular expression metacharacters if you're piping Freshen
> --no-colours through it.
>

--no-colour gave me this:

Freshen: ERROR: exceptions.NameError: global name 'Screen' is not defined

Traceback (most recent call last):
  File "/System/Links/Executables/Freshen", line 410, in <module>
    ui = FreshenUI()
  File "/System/Links/Executables/Freshen", line 50, in __init__
    self.args = FreshenArgParser.FreshenArgParser(self)
  File "/System/Links/Libraries/python2.3/site-packages/FreshenArgParser.py", 
line 24, in __init__
    self.fetch()
  File "/System/Links/Libraries/python2.3/site-packages/FreshenArgParser.py", 
line 75, in fetch
    for c in Screen.colours:
NameError: global name 'Screen' is not defined

Freshen 3.0.2 on python 2.5.2.final.0
arguments: ['/System/Links/Executables/Freshen', '--no-colour']

> For what you're doing, SVN Freshen/Scripts and the -p option will do
> what you want. That also required some CheckDependencies fixes, so I
> can't release it until there's a new Scripts out.
>

ok, looking forward to the release :) im guessing there is a -r (recipes) as 
well?

> >> > 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".
>
> Not even that, it just shows *a* program higher up that is already
> installed (or listed explicitly on the command line). Consider this
> example:
> A depends on B, and an older version is already installed.
> B depends on C, and an older version is already installed installed.
> C is not installed.
> Here, you could get *either* A or B listed as introducing C, and it's
> completely arbitrary which it will be.
>

ah, thanks for the clarification.

> >> > 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.
>
> It's (in effect) topologically sorted. Every program comes after all
> of its dependencies, but positioning other than that is undefined.
> There are many possible topological sorts for a given graph, so you
> may get a drastically different order when you choose only part of it.
> --unordered is in arbitrary order, with no dependencies listed.
>

ok, so the further towards the top of the list it is, the more likely it is 
that its the dependencie of something further down? so in essence i should 
start at the bottom of the list, working upwards to get a sense of what i 
should think about updating?

> > 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.
>
> Whichever one comes first will introduce it somewhere before itself,
> listed as introduced by it if not already installed. Every other
> program using it will see that it's already in the list and continue
> happily along with the rest of its dependencies.

ok, ill try to keep it in mind.