In Vbox Using an up-to-date M3 install then updating that install with: Mageia 4 RC - DVD 32 bits DATE.txt: Sat Jan 11 23:18:43 CET 2014 Mageia-4-RC-i586-DVD.iso MD5SUM: 95bbfd65c47d0d97e7a003a9c1fe9f3a Results in the Apache function on the original M3 install to loose the User Directory ( public_html ) function. Simply setting up the new M4 Repos then installing apache-mod_userdir, then restarting httpd, corrected the problem. Reproducible: Steps to Reproduce:
Whiteboard: (none) => 4RC
did you continue your update with urpmi after the first reboot on mga4 ? (as apache-mod_userdir is not in the iso)
What I did was to leave the M3 install alone with it's M3 repo then use the M4RC iso ( USB memory stick ) to run the Upgrade. That completed normally, rebooted, then returned to a working desktop but as an M4 system but still with the M3 repo. I noted at that time that apache-mod_userdir was not installed. It had been installed on the original M3 install. I then removed the M3 repo and set the new M4 Upgrade to the M4 repo and using the MCC installed the apache-mod_userdir module. I then stopped httpd, restarted it and all was good. Yes, I assume that apache-mod_userdir is not in the iso and probably should not be. httpd is an add in app that is done after basic install. I'm not sure this is a problem at all. Likely anyone installing Apache will have some knowledge of it's structure and go through the steps I went through.
Same condition persists in M4 64-bit.
This has nothing to do with installer. It's a packaging issue
CC: (none) => guillomovitch, mageia, oe, thierry.vignaudComponent: Installer => RPM PackagesSource RPM: (none) => apache
Is it an issue at all? I don't understand. apache-mod_userdir is packaged and functioning correctly, yes? So if you need it you install it. What's the issue?
CC: (none) => luigiwalser
(In reply to David Walser from comment #5) > Is it an issue at all? I agree. I just wanted to get some discussion of this. If by consensus we can agree that someone with Apache already installed on their M3 system and when upgrading to M4, by whatever means they would go through and insure the needed modules are installed. Not expecting that all of them would be installed during the upgrade. Then I would agree that this is not an issue and this can be ignored. They're are probably other applications that do similar things. I use ProFTP and sshd and those to apps had no problems during the upgrade.
If you had apache-mod_userdir installed, it should be upgraded. Otherwise, if you didn't have it installed, it won't be installed.
(In reply to David Walser from comment #7) > If you had apache-mod_userdir installed, it should be upgraded. Otherwise, > if you didn't have it installed, it won't be installed. Install of apache-mod_userdir is part of my basic testing Vbox image. It was not carried forward in the M4 upgrade. I've tried it a couple times and it didn't get carried forward.
(In reply to William Kenney from comment #8) > Install of apache-mod_userdir is part of my basic testing Vbox image. > It was not carried forward in the M4 upgrade. I've tried it a > couple times and it didn't get carried forward. Not carried forward? You mean it actually uninstalled it? Do you have a log showing why it did this? I did not experience that in my testing.
OK, of course I didn't do my testing with the DVD, I had full repository access. I'm guessing what happened is, since mod_userdir isn't on the DVD and it requires apache = %{version}-%{release}, upgrading just apache would break this so it said something like apache-mod_userdir has to be removed for apache to be upgraded. The requires should be apache >= %{version}-%{release} and that would fix this.
OK I committed that in SVN and did it for all of the modules. I did not do the same for apache-devel, so hopefully that's on the DVD, but I suppose if that gets removed on upgrade it's not a big deal. I need to ask for a freeze push, but I'll do it tomorrow (if I remember) just in case anyone has any feedback.
apache-2.4.7-5.mga4 uploaded which should fix this.
Status: NEW => RESOLVEDResolution: (none) => FIXED