Just to follow this one up: Here is the debian package I made based on Eric's previous package for 2.0.x
http://nietsch.demon.nl/~jib/xoops-2.2.3afinal/xoops_2.2.3aFinal_all.deb

I'm on a puny dsl so please do not pound it please.

I will not release any more packages as I have bee terribly unimpressed with how things start off after an install. The only upside I can think of after spending this much time on packaging it is that I hve learnt some more on how to make a debian package. The XOOPS part was mostly wasted.

So long....

Maybe you should ask your hosting provider instead of here?

Yes and no,
It is what I meant, but what does the script have to do specifically in case of an upgrade? for a new install I have it create a bd and dbuser, load the sql structure and initial content and then ask for and save the XOOPS admin.
but what in case of an upgrade? create a db backup before proceeding? and then what & how?

Sometimes you do what is neccesary, so I started building Erick Castellanos package and tried to upgrade it to 2.2.3afinal. It is not finished yet(see other post about that) I still need some hint what to do in the case of an upgrade. (and it does not install a working version too...).

Hi Folks,

Out of necesity I have started to package XOOPS in a debian .deb package. As I am new to xoops, I don't really know what to expect wrt to upgrading XOOPS without intervention. I have not started from scratch but used the source from Erick Castellanos' package for XOOPS 2.0.9.2-3 and tried updating it to 2.2.3afinal.

Before you rush out and direct to the manual update procedure for windows user deploying on hosting service: hold your horses, this is more comparable to a local installation on a linux distro(in fact it is how it should be done, installing from a tar.gz file is bad)

If you do not know how package management(apt-get, yum) works, here is a quick lineout:
(if you are familiar with it, skip down two paragraphs)
A package only contains its own software. If it needs other software or libraries those dependencies are mentioned in a special file in the package. The package will not install before those dependencies are fullfilled. To make sure all needed software gets installed when you want a certain package, you use apt-get (or yum) that knows what software is available for install and can (try to) solve the dependencies of a package.
So what happens when you install a .deb package?(or .rpm on other distro's): the package manager will fist make sure all dependencies are met. next it will run any scripts that come with the package that need to be run before installing. Then it will unpack all the files to their destination. the last step is to run the post-installation script. Every script can ask the user to answer certain questions (only on debian), like what should the password for the new database be, but those questions should be kept to the absolute minimum. On redhat no questions can be asked, so that upgrades can be scheduled without needing root's attention. similar script are run when the package is removed or purged from the system.
When you don't install a new package, but upgrade to a newer version, the old version is passed on to the package, so the scripts can do the right thing with upgrading.

So most things that need to be done during a manual installation of XOOPS or that are done by the 'installer' can be done from the scripts that come with the package, but the requirement is that these should be complete. A package that needs the user to go call a certain upgrade script or XOOPS won't work correctly, is considered broken.

All that introduction was to ask you the following question: what do you think the post-install script of the package needs to do in case of a new install and in case of a upgrade from a specified (but unknown when building the package) version?

Here is what I have so far (most of it was already written by Erick Castellanos who wrote the previous package)
in case of a new install:
# Get the info (name, email, password) for the XOOPS admin.
# Create the XOOPS databse with the name 'xoops' with user 'xoops' and a random password.
# load the structure of the db
# load some initial data in the db
# write the random password in mainfile.php
# set the permission of mainfile.php to read-only.
# create & set the owner to the apache user for uploads, cache and template_c.
# link the apache configuration script into the apache conf.d dir and restart apache.
esac

But for the case of an upgrade I don't have any code yet. what should be done in that case? All the code from the full download is included in the package, but is that enough or do I need stuff from the 'upgrade' downloads too? I had a quick look at an upgrade php script I could find, but I noticed that it required a valid an authorized login. Is there a way around that? Does it cover all possible upgrade cases?9ok that is a moot point, few other XOOPS debian packages have been made) It should be possible in theory, as the postinst script gets run with root permission.

Any suggestions?

@Lance_: Maybe I have notexplained Linux package management good enough. I will start a new thread as this does not fit the topic very good.

Hi, I am trying to build a debian package for xoops, and this bugged me too: what is in the purpose of the upgrade patches? Are that only the updated files or is there some more logic in them?
If i overwrite an older version with a new release, what do i have to do to make sure the rest of the system gets upgraded ?(DB updates etc.)

If one has to be logged in to run this upograde script, then there is no way to do this automatically when the software gets updated, which might mean the XOOPS site gets broken after an apt-get upgrade. Not what you want.

Why would you think he was hacked? SugarCRM is just a Open source CRM package. If it were a 'bot' why would it want to redirect to a local package? 'Never attribute to malice what can be explained by inpompetence'.
I think he(or someone else) has been playing with apache rewrites that redirects all requests to the sugarcrm login. check if your .htacces is empty or all lines there really belong there.
remove all files (also the hidden .files!) add one simple index.html and test if that works. make sure you have a clean slate before you install again.
good luck!

Quote:

Well, you might be a fellow Linux user, but you do not seem very well versed in the why and hows of package management. If you admin a linux box that uses package management you try to avoid installing any system software from a tarball at all costs. Most (if not all software) gets developed upon, adding features and fixing bugs and security leaks. The extra features you can do without, but the bug fixes and especially the security fixes are something you should wish to monitor all the time.
A typical Linux distro has over a thousand packages installed, so it would be totally impossible to keep track of all of them acurately. That is one reason why those tasks are centralized in the package management/repository.
If some nasty stuff is discovered in a package, all I have to do is run apt-get update && apt-get upgrade. This will make sure I get the latest available software installed without further action needed from me. Also when I install from scratch All I have to do is answer some questions and be done with it. No need to make sure I have a database available etc. Somebody still has to make the package, that is true, but the total amount of work spend on upgrading by all users is far less compared to everybody doing their upgrades manually.
A second reason to use package management is to keep track of all installed files an be able to unstall some particular software later on. you will not be able to do that if you install from tarballs, you will quickly loose track. Lastly package management is nothing new, most (if not all) distro's use it. It is only new for you if you come a envirnoment where there is no system-wide package manager, like windows. You can compare apt-get and yum on linux with windows-update, but with the exception that all sofware is installed and updated with it, not only the MS-squeeky-wheels.

And offcourse I too support a call for a debian/rpm package. It appears the package mentioned above has not been touoch in a year.