On Tue, 18 Mar 2008 01:59:58 +0100, Carlo Calica <[EMAIL PROTECTED]> wrote:
> On 3/17/08, Hisham <[EMAIL PROTECTED]> wrote: >> >> > >> > Broken Links after install (199): RemoveBroken needs to be run in >> Installer? >> > > > Comments? > RemoveBroken should be run by the installer (the code is there). Somehow it isn't, i.e. it's a real bug. It also breaks compilation for some applications (applications that need to run autoconf/automake). >> > Sudo overwrites files (204): This is a longstanding problems. There >> > is a suggested change to the sudo recipe in the bug tracker. Has the >> > recipe been updated? >> > > > I've experienced this countless times. If we have a fix, this really > should go in. (Bug moved to 014) > Has anyone tried Hisham's fix as he posted in the comment to the bug? >> >> > Now, to talk about PostInstall. I'm going to be a bit verbose because >> > I won't be there tomorrow to respond to question regarding what I >> > mean. The PostInstall script is run to create an EFFECT (I'll use >> > this a lot) on the system (create id/keys, set ownership based on >> > created user/group, etc). This effect should be distinct for each >> > install. The LiveCD is a type of install. It should be affected by >> > the PostInstall scripts. Whether this happens during ISO generation >> > or boot is debateable but probably minor. >> > >> > So the LiveCD needs PostInstall effects. These effects should not be >> > mirrored to the HD during install. During install, PostInstall needs >> > to be run to generate the distinct effects for that system. >> > >> > I'm worried that Installer is not sophisticated enough to prevent >> > transferring the LiveCD effects to the HD. There are only 4 >> > PostInstall scripts on the LiveCD, so they can be special cased for >> > 014.b but a plan for general use would be great for beyond. Similar >> > concerns apply for R/Requirements as well. >> >> >> I believe the effects applied to the LiveCD environment all go into >> Settings directories and the user's home directory, while the >> Installer does not use these directories, using each package's >> Defaults/Settings instead. IIRC, André was the one who worked on this, >> so he may be able to confirm. In this case, we shouldn't have a >> problem running PostInstalls (for example) on LiveCD boot for the >> LiveCD environment, and then running them again for the installed >> system. >> > > This needs to be investigated and decided whether to include for 014.b or not. > I think Lucas has commited changes to ProfileInstall and PostInstall so that PostInstall scripts are run by ProfileInstall for the install prefix after all applications are installed. However, should Settings and Variable be copied at all from the LiveCD to the install? As we do it now we copy the entire application directory, including any Settings and Variable. Though we delete the Settings directory for those applications that has Default/Settings we keep the others. I also noticed that we don't install unmanaged files, or did I miss something? >> > On IRC, Jonas and I discussed upping KDE to 3.5.9. At that point, I >> > started to think that 014.b could be more than a bugfix release. >> > Keeping the stage 1 core, updating the stage 2 desktop and stage 3 >> > apps. With the timeline, I'm sure that is not feasible. I'd like more >> > details wrt pressing CD. Is this for a magazine? Is it worth the >> > rush? Especially since 014 is a little dated. >> >> Given that KDE 3.5.9 itself is also a bugfix release, I'm kinda >> favorable to that idea as well. >> > > Still an open issue. Jonas knows a bug (not in tracker) in KDE-Base. > I guess we can try 3.5.9 and fallback to 3.5.8 if problems arise. > Someone volunteer to build packages? > For the record (bug tracker still unable to accept new bugs) the bug is that kdmrc has hardcoded paths to the specific Xorg version KDE-Base was built against, rendering KDM unable to start if Xorg is updated. -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
