Looking through the archives for something else I noticed this and that it never got a response when it should have; I'll try now. On Sun, Nov 16, 2008 at 11:17 AM, CR <j5m9s6...@sneakemail.com> wrote: > Hi all. > > My problems with Gobo stem from installing/compiling big packages with > complicated or large dependencies. X.Org or KDE are both good examples of > "complicated" packages. My comments are based of use of the very latest > scripts (Scripts 2.9.0, Compile 1.11.0) > > The way I see it, if you want to install a new package or re-install a > package you have to deal with the following situation(s): > > 1a. Preserve or keep your existing configuration files > > 1b. Overwrite your existing configuration files > > 1c. Some mix of 1a/1b > 1. Prompt user if he wants to backup all relevant configuration files. > > This spawns a bzip2 of the Settings folder for relevant packages to be > updated and gets stored in some archival folder in Settings or elsewhere. > > Perhaps the actual backup occurs right before the installation/compiling of > any packages so no time is wasted. > (I have spliced the relevant portion from later in the message next to its partner here). Settings files are never overwritten if they have been changed and never deleted by default. They are installed into R/D/Settings, whence UpdateSettings will take them to compare with the current settings and see what you need to merge, or what else you need to do. The only settings change that can happen transparently is the addition of a file or the replacement of the default, unchanged file with the new default.
However, a settings-backup script would be handy anyway and could be cut into the tools. > > 2a. Preserve your existing (perhaps out of date) dependencies > > 2b. Install the latest and greatest dependencies > > 2c. Some mix of 2a/2b > > In addition to those choices, with Gobo, you have a problem of unnecessary > or irrelevant dependencies getting thrown in. > > An example: I tried to InstallPackage X.Org and was prompted to install a > newer version of GCC. A new version of GCC shouldn't affect X.Org's > operation, at least for a binary package. This is not true, *especially* for a binary package. Take a look in /P/GCC/Current/lib for a pile of things X can (and evidently does) link against. It may turn out that the package will work anyway because X didn't specifically rely on the later version, but you can't rely on that to be true. Even if it does seem to work there could be another problem hidden away. In general dependencies are even stronger for binary packages than for recipes (because linking is much stricter than just compiles-against). They should be forward compatible; backwards is usually a no-go. > There is also the problem of "meta-packages" like KDE. If I want KDE 3.5.8, > then I want everything that goes along with that (KDE-Libs, KDE- > Applications, etc). I know Gobo has this concept, but browsing for "KDE > 3.5.8" still gives me the sub-packages. I think the sub-packages should > fall under one "KDE 3.5.8", but remain optional dependencies for the user. There is an overarching recipe, but not package. I think a package should be doable though and probably will be made in future - just that binary package updates are a bit slow at the moment, especially for big and complex software like KDE. An empty package is simple enough, but not really a high priority. > 2a. Present a list of ALL dependent packages so the user can go through the > list and select which ones to update and which ones to preserve. In some > situations an updated version of a package is really needed and in other > cases it doesn't matter. The real nature of the dependency should be > tracked with >= x.x.x > > OR > > 2b. Let user select to install ALL necessary dependencies, including latest > versions. If you're installing binary packages, the dependencies should be presumed mandatory. If you don't install them, it may work fine, it may work but unreliably, or it may not work at all, and knowing which is which a priori is next to impossible. Sometimes you can tell (patch updates of libraries in interpreted languages, say, or non-linking optional dependencies), and you do have the option of skipping them if so, but it's on you if you do. If you don't know what you're doing with them, you should install. 2a can be accomplished with Freshen. > 3a. Provide user option to overwrite ALL configuration files for newly > installable dependent packages This could be a useful feature sometimes. Perhaps not as often as you'd think, but sometimes. > 3b. Or let user selectively choose which packages should use updated > configuration files and which should get overwritten with default/latest. You can do this now, though you do have to go file-by-file. Perhaps [UA]Use All would be a good addition to UpdateSettings. Maybe even [R]eplace (delete current and use all) for Udev-alikes. Patches welcome. > I would envision this using some GUI (an updated version of Manager?) and a > text-based GUI (like menuconfig). > > With the above choices, once everything is selected, there should be ZERO > prompting from the user, everything should just happen. > > Maybe a command-line switch for Compile/InstallPackage -ua == update-all > implies install all needed dependencies, install latest and default > configuration files? See Freshen, in particular `Freshen -m ...` and `Freshen -U ...`. A GUI would be welcome for that too. > To deal with unnecessary dependencies, I think we'd need a hierarchical > black and greylist and subdivide packages (like GCC) into categories, so we > can filter by default. > However if you were installing, say GCC, you might want binutils or whatever > which would be include since they are in the same category. No categories. They're a nightmare to maintain. Partitioning the programs like that leads to all sorts of nasty edge cases where you try to figure out where something goes, and you'll end up with either uselessly-broad or -narrow categories that people just learn to ignore. A tagging system has come up once or twice and is a possibility, but really intended for searching more than this sort of automated administration. I'm not sure if it'd fit in here or not. > For example, if GCC exists in Development, and you're installing X.Org, you > can exclude all Development packages so GCC would never become a dependency > of XOrg (by default). And this is another flaw in the system - GCC has been miscategorised, and packages will be unusable because GCC really is a dependency. libstdc++ is a part of GCC, which is frequently why it shows up. The same is often true of other packages. In general you just can't leave out a dependency that comes up from ldd - really the only time is when it's only used in a dynloaded module. Non-linking dependencies have been added deliberately and could be on either side of the divide, but I don't see a way to tell. Flag information might help a little. > Finally, many of the devels. here can rightfully respond by saying "we'll > accept all patches". Frankly my gifts are not in coding but I would > certainly pledge my time and effort to help out. I think we should at least > come to a consensus whether or not the proposed features have meaning. I > don't think I'm the only person fighting these problems We'd never say that. We'll accept all *good* patches. But hey, the code is pretty clear, maybe you could dive in all the same... If not, these kinds of reports are useful for pointing out places that are or seem awkward to end users. I think a couple of those UpdateSettings ideas are worthwhile and hopefully someone will look into them. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
