On 10/22/06, Hisham Muhammad <[EMAIL PROTECTED]> wrote: > I'm not sure. Old packages have all sorts of problems (bad > dependencies, bad Dependencies, etc.) and many are seriously outdated. > The 013 store, in contrast, is much cleaner (wasn't it almost entirely > built using ChrootCompile?) and doing this "reboot" of the store gives > us the chance to increase the overall quality of our binary store to a > new level. Sure, it would become much smaller, but now we have Compile > (and ChrootCompile) which means we'll be able to fill up the binary > store much more efficiently, I think. > > Also, one of my post-013 plans is to add full support for the rXpY > recipe/package revision numbering scheme in scripts, so having a > mostly new package store is a chance to 'restart clean' on that arena > as well.
No problem for me, as long as we got to "fix" remaining relevant recipes soon making them compileable inside ChrootCompile. Based on my experience of compiling packages for 013, most recipes needed at least some adjustment, being the addition of a "BuildDependencies" file the most common case. > We can keep the old package repository available with an "unsupported" > status, not unlike like the "contrib" repo. Not sure about this. Actually, as I see, there is not much reason to keep contrib / unsupported packages at our repositories once we got correct recipes (i.e. which work under ChrootCompile) and a basic environment on which to run ChrootCompile commands more or less automatically. > > > The procedure for safely installing Glibc 2.4 in a exiting system is > > > quite simple, but requires a small additional step: > > > > > > 1 - Become superuser > > > # a superuser terminal has to be open before running step 2 > > > # since you will not be able to perform 'su' or 'sudo' after step 2 > > > and before step 3 > > > 2 - InstallPackage Glibc--2.4--i686.tar.bz2 > > > # there is no need to update any file inside the Settings directory > > > 3 - cd /Programs/Glibc; mv 2.3.2 old_2.3.2 > > > # a rm -rf could be performed as well, but having keeping a backup may > > > be useful > > > # if something goes wrong (having a live cd copy available might be > > > also useful :) > > Interesting. Any idea why it is so? No, but I've tested this twice: First time, trying to figure out what was happening, trying a lot of things (unsuccessfully) until I moved the 2.3.2 directory and thing started to work again. Second time, doing the process above directly, and noticing that it was enough. > > > The most straightforward for us would be to ask users to perform this > > > upgrade when willing to use newer packages, but I'm not sure how can > > > we enforce this. > > Through dependencies. Once CheckDependencies is able to fetch its > dependencies off the network separately from the package, we can make > InstallPackage check dependencies before installing the package. If > dependencies cannot be met, then the user will have to answer "y" to > something like "This package requires Glibc >= 2.4 but you chose not > to install it. Proceed anyway?" I need to think a little bit more about it, but I don't like much the approach of inserting such specific interation within CheckDependencies. Maybe we can remove Glibc from the blacklist (remember that on recipe Dependencies, the version of the dependency is ignore if no explicit >= rule is specified) and add a special handling inside InstallPackage, running the commands I've wrote above (in a more general fashion). Something like a post installation script. Jut to remember, we already have a special case being handled inside InstallPackage (for Scripts). Anyway, we would need to expect the user to upgrade the scripts package before using newer packages. > > Talking about Glibc, don't we need to instruct InstallPackage to take > > them from the 013 store instead of the old one? I'm thinking about > > letting it take into account /System/Settings/GoboLinuxVersion, using > > the 012 store as a fallback. I know this is a bit later, but I forgot > > about this topic until now. What do you think? > > I don't like the idea. In particular, GoboLinuxVersion does not say > much (if anything) about the actual status of the system; dependencies > is the way to go. I also didn't like the idea. -- Andre Detsch _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
