2007/3/8, Michael Homer <[EMAIL PROTECTED]>: > On 3/8/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > > 2007/3/7, Michael Homer <[EMAIL PROTECTED]>: > > > Hi, > > > I've finished a pre-release new version of Freshen, that's had all the > > > features updated so that they actually work as expected. As well as > > > that, there are a couple of new features: > > > - upgrade-system actually works now, and pretty much flawlessly. I've > > > just used it to update mine. > > Why does upgrade-system try to upgrade 320 apps, while Freshen only > > lists 162 apps as "upgradeable"? > They should be exactly the same list - the only difference between the > two is that one outputs the entries and one calls > InstallPackage/Compile on them. Are there duplicates in the list? > There shouldn't be any difference between the two reported counts, > either > > Also compare with `Freshen | wc -l`. I have noticed that some packages > get listed in the output without being flagged as [U]pgradable, which > is cosmetic only. If they're in the list, they'll be upgraded.
Ok, I was using the numbers put by Freshen. 'Freshen' says: "Upgrades: 162 Downgrades: 0 Total: 162" while 'Freshen -U' says: "Freshen: Upgrading 1/320..." Is there any way to tell what list 'Freshen -U' uses, i.e. what applications it's going to upgrade? > > > > > > I'm posting this here rather than on -users because I'd like to have > > > it go through a little bit of real-world testing, particularly the > > > upgrade-system feature. I suggest limiting the number of programs it > > > will update and making sure things are still as they should be after - > > > the -l command-line option deals with this. > > > > > I can't make Freshen use binaries. If I use '-b -R' options I get an > > empty list, even though I know there exists newer packages for apps > > that I have installed. > Run `ls -l /tmp/BinaryPackages(List|Data)`. They should both be > non-empty. It also only checks the package repository set in > Freshen.conf, so check that that's valid. > Ok, '/tmp/BinaryPackagesList' was empty, that explains that. I think it would be a good idea to parse Compile.conf for variables like 'getRecipeStores' and parse GetAvailable for variables like 'officialPackagesLists' and 'defaultLocalPackagesPaths' instead of having them defined in multiple files on the system. As it is now, if one wants to change the repository one has to change two files. > Another thing that occurs to me is that it relies on parsing the > directory listing HTML - I haven't tested it against all the > repositories, only gobo.calica.com. That could well be the problem. > See if changing the defined repository there makes it work; another > symptom would be that BinaryPackagesData is full and > BinaryPackagesList empty (one is just a parsed version of the other). > If that is the problem I'll have to tidy up the parser, or make it > cheat and always use gobo.calica.com/gobo/packages/official/ for the > packages list. > Instead of parse the HTML, can't you just use the MANIFEST/MANIFEST.bz2 file? > > I still haven't had the guts to try upgrade-system. :) > Freshen -l 5 will show you the first five programs, that will be > updated by Freshen -U -l 5. You can keep an eye on things and make > sure they're going ok by using those. There shouldn't be any problem > with it; the worst that can happen is a bunch of package installs > fail. Ok, I'll try that then. :) Great app btw. -- /Jonas _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
