On Sat, 2005-11-12 at 20:43 +0000, Chris Cannam wrote: > I know this is all old hat, and I understand this is why Autopackage > exists. I just don't believe, on the evidence I've seen, that > Autopackage works well enough. It's also pretty much why Studio to Go! > exists, come to that (that and the possibility of making some money > back).
Well, we always appreciate help in making autopackage more compatible. As you already know I guess, it was made to reduce work for both end users and developers (and increase testing, and usability, and predictability etc). If you feel you still need to rely on distributions because autopackage isn't good enough then that should be fixed. > OK, I gritted my teeth and downloaded the 0.42.2 autopackage. I > pretended I didn't know the root password, so as to get it installed in > my home directory. (Incidentally, autopackage should probably warn you > that it's installing potentially huge amounts of stuff in a dotfile Yes, possibly so. We install to ~/.local partly for compatibility: we didn't choose that directory ourselves. Also, I'm not sure it's a good idea to expose the innards of program contents through the file manager by default, it's a bit like a TV having all the circuit boards and wires exposed. Not very nice. That said, the disk space issue is well put .... IIRC we show how much disk space is being used in the manager applet. But it doesn't say where the program was installed to. > The result was broadly good. It installed a version of Inkscape that > seems to work. (Judging from the ldd output, Inkscape is in C, right? Inkscape is written in C++ and uses the GTKmm bindings. It also uses Boehm garbage collection. They're all statically linked as these deps are quite rare and many users didn't have them (especially libgc). > All of the dependent libraries > were already present in /usr/lib except for libpng1.2.so.0.1.2.8 which > is found in ~/.local (dated some time in July, I don't know whether > that's from a package previously installed using Autopackage or what). I guess it must be. I don't think we install libpng, but we do add a symlink on some systems. I suspect it came from Lilypond, this package is *very* unusual in that the developers feel any failed dependency at all is bad so they ship basically the entire OS except for the kernel and libc in their package. This includes things like libpng, Pango, GTK+ etc .... I've asked them not to do that before but at the end of the day, it's their choice. That's decentralisation for you ;) > However, it did do the profoundly annoying thing that I remember from > last time, which is that it blitzed my carefully tweaked K menu made > with KMenuEdit (~/.config/menus/applications-kmenuedit.menu) and > replaced it with a version of the Debian menu which it wrote into > ~/.config/menus/debian-menu.menu. It actually deleted my original file > altogether, without asking or creating a backup! Ouch! Sorry about that. When I read this I have gone over the installMenuItem() code quite carefully, and didn't see any code that could trigger this behaviour, indeed I don't see any references to these files or anything that could match them at all. The only suspicious thing I saw is that in some cases we run the Debian update-menus tool. Maybe update-menus is responsible somehow for what you see? > (Incidentally, the last time I tried an Autopackage was for Lilypond. > First it complained that I didn't have a new enough version of > Ghostscript -- I thought Autopackage was supposed to avoid that sort of > problem? -- I can't remember whether it refused to install and I > pacified it by installing a newer version, or whether it was possible > to overrule it somehow. Then it installed a binary that didn't work > because of C++ binary incompatibilities, and blitzed my K menu. It was > wrong in just so many ways that I really didn't fancy trying to follow > up any fixes, which is why I didn't report it.) That is very unfortunate. Most package work better than that: * There is something special about Ghostscript and Lilypond. I don't remember what the issue is exactly but I think it's very hard to bundle in the package for some reason (or the Lilypond developers refuse to do so). Anyway, we can provide the tools, but can't make people use them. Inkscape is a textbook case of how to get an autopackage right - the commonly available dependencies like GTK+ are dynamically linked against, the rare ones are statically linked or bundled. It's too bad you chose such a ... uh ... unique package to start with :( * C++ binary compatibility issues are something we've put a lot of work into for the next 1.2.x releases, and we're in the last stages of ironing out the problems. They don't affect every C++ app which is why Inkscape is OK. Qt apps are bit the hardest obviously, but the new support in 1.2 can transparently fix it for every C++ app. So .... yes. It's not good. We warn developers of C++ apps to be careful and advise when it'll work and when it won't, but again, we can't stop people who really want to go ahead anyway. * Menus - well this is a mystery. Menu problems are nothing new, this is such a mess on Linux, but I never heard of autopackage deleting peoples modifications before. It needs to be investigated and fixed. thanks -mike ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
