[gobolinux-users] exclude localrecipes from freshen and friends?
Michael Homer
michael at gobolinux.org
Thu May 22 12:42:15 NZST 2008
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.
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.
>> > 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.
>> > 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.
> 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.
-Michael
More information about the gobolinux-users
mailing list