On 10/22/06, André Detsch <[EMAIL PROTECTED]> wrote: > 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.
Sounds fair. > > 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. Ok. Then let's move all contrib and old packages to a big "unsupported" repo that will be phased out as soon as practical. > > > > 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. Yes, sounds tricky, and quite possibly the reason why upgrading Glibc seems painless for some and painful for others. > > > > 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. I didn't mean as a specific Glibc thing. The idea would be to have CheckDependencies return a different error code if the user skipped any required dependencies and have InstallPackage ask for confirmation in that case. We're used to run "skip, skip, skip" on dependencies check because our dependencies files keep asking stuff such as "program requires Xorg 7 and you have Xorg 6.8" (when in fact the dependency should be just Xorg without a version, for example). When dependencies specify specific ranges and those are skipped by the user, that will be a much stronger indication that something may go wrong. > 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). Well pointed. But Scripts are the "recursive" case, so that makes sense. > Anyway, we would need to expect the user to upgrade the scripts > package before using newer packages. Which, for 012 users, is acceptable, I think. For 013 users that won't be a problem. -- Hisham _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
