On 3/13/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > 2007/3/12, Michael Homer <[EMAIL PROTECTED]>: > > On 3/9/07, Michael Homer <[EMAIL PROTECTED]> wrote: > > > On 3/9/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > > > > > > > > A feature that I think would be nice is to see why an application is > > > > in the list, i.e. what application that had that dependency. > > > Good idea. I will add that, possibly for the release after this one > > > since it may not be simple. > > > > > > I'm actually not sure how well the addition of uninstalled > > > dependencies to the tree is working - it's more of a happy accident of > > > the sorting algorithm than by design at this point. If you notice any > > > bugs with it let me know. In particular, I've just realised that I > > > don't think their own dependencies are included in the calculations. > > I haven't found any real bugs in the sorting algorithm, but what I had > in mind was to get a list of applications that pulled in an > application in to the list, next to the listed application. There isn't really room for that, but Freshen -V -i program does give you that list. The problem with putting it directly into the list, aside from just a space issue, is that it's expensive to generate - essentially the only way to do it is to run through the entire dataset and search.
I will try adding it in the list for N-tagged programs only, at verbose and above, and see how it comes out. > > > Ok. So I've done pretty much all of that, tested it, it all seems to > > be functioning. If there are no major problems, I'll tag this as 2.1 > > final and get a recipe out as well. > > I still get some error when an older version then the available is > symlinked as current: > > Freshen: Attempting to fetch recipe dependencies for Xorg > GetRecipe: Recipe for Xorg none not found > Freshen: Attempting to fetch package dependencies for Xorg 7.2-r1 There was a bug in how it compared versions pulled from /F/C/R. It may have caused this - I don't think it's related to which version is symlinked current though, since it looked for a valid package version. Freshen will assume that the newest installed version is symlinked in at all times, since otherwise it'll try to install it, but that will cause errors if something depends on that newer version and can't find it. All the ways around that are a bit of a hack. > > And Freshen died with this error: > > Freshen: Notice: dependency file for KDE-Libs has incorrect > capitalisation on NAS > Freshen: Freshen: Error: undefined method `set?' for nil:NilClass > [NoMethodError] > > When I looked into it I can find no recipe for NAS, so I guess that's > the problem. However the error message isn't that descriptive. :) > After I ran 'GetRecipe KDE-Libs' the error got away, so my guess it > that that dependency listing is in an old version of the recipe, but I > couldn't find any KDE-Libs recipe or installed package of KDE-Libs > that listed that dependency, so I don't know where Freshen got that > from. > > I got the same error from another package, GLSavers-NR: > > Freshen: Notice: dependency file for GLSavers-NR has incorrect > capitalisation on Nvidia > Freshen: Freshen: Error: undefined method `set?' for nil:NilClass > [NoMethodError] > > The strange thing is that I cannot see what application made Freshen > try to look at this recipe/package. There's no application that has > GLSavers-NR as dependency afaik. I tried to grep for it, but couldn't > find anything. Here's where that dependency list thing I suggested > would come in handy. 'Freshen --info GLSavers-NR' dies with > > Freshen: Generating list of installed programs... > Freshen: Freshen: Error: undefined method `each' for nil:NilClass > [NoMethodError] > > so I can't tell what's wrong. The "incorrect capitalisation" error isn't always true; it's just a guess, since that was the most common way it came up (for me). It emits that, and then searches /Programs and all the recipe directories for entries with the same name ignoring case, then assumes that's the correct name and tries again until it runs out of possibilities. If it doesn't find one at all it dies, since it can't possibly resolve the tree without complete data. Try `grep GLSavers-NR /tmp/dependencies-*` and see what you get. That'll show you if a package dependency file has pulled it in. If not, it's possible that it's already installed, or at least that /Programs/GLSavers-NR exists. Add "--debug" to your parameters, or put "verbosity=debug" into your config file and it'll generate backtraces. That will help find where the error is. I will put a hold on the 2.1 release while I sort these out - thanks for the testing, it's always difficult to handle the edge cases that don't come up on my system. There's also a problem right now in that Mesa and Xorg both depend on each other, and so it dies on a circular dependency. I'm not sure how I'll deal with that. For now I have special-cased it to remove Xorg from Mesa's dependencies. I have uploaded a new package to http://gobo.wotfun.com/Freshen--2.0.9991--i686.tar.bz2 - it should go some way towards resolving those problems, I hope. I think some of them will still come up, but with backtraces I'll be able to fix them. > > > > Package attached. Configuration file change is the addition of the > > fetchAllPackageLists option. > > > > By the way, in creating the package I got a pile of errors in this form: > > /Programs/Scripts/2.6.3/bin/../Functions/File: line 130: > > /Programs/Freshen/2.0.999/Resources/FileHash: Permission denied > > `sudo CreatePackage` did not help. So the package is not signed, so it > > probably needs a manual SymlinkProgram after installation. It seems > > from looking in Functions/File that that would mean packages can only > > be created as root, since $hashfile will never be world-writable. `| > > $sudo_exec tee -a "$hashfile" > /dev/null`? > > What was your permissions? $sudo_exec should be set to "sudo -u #0" > and should therefore be able to write to that file as long as any user > has write permissions. But packages without signature is better than > packages with invalid signatures, as the former will be symlinked at > install while the latter will have to be manually symlinked. The full block is: $sudo_exec ListProgramFiles --files "$file_prefix" | grep -v "Resources/FileHash" | while read file do $sudo_exec sha1sum "$file" >> "$hashfile" done My reading of that is that ListProgramFiles is run sudo and sha1sum is run sudo, and not the while block - if it were, sudo on sha1sum would be unnecessary. That means that >> is done as the executing user, not root, and the executing user may not have write permissions Running as sudo doesn't do anything to help though, exactly the same errors occur. /Programs/Freshen/2.0.999/Resources is drwxr-xr-x all the way up the tree, owned by root. The package I just uploaded is signed, but I had to chmod a+w /P/Freshen/2.0.9991/Resources manually to do it, which isn't a problem in practice, now that I know to do it. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
