[ php-blog-Bugs-2992079 ] make s9y friendlier for downstream

Bugs item #2992079, was opened at 2010-04-25 21:11
Message generated for change (Comment added) made by jmroth
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=542822&aid=2992079&group_id=75065

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installer/Upgrader
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: J.M. Roth (jmroth)
Assigned to: Nobody/Anonymous (nobody)
Summary: make s9y friendlier for downstream

Initial Comment:
When packaging this application it 
- may be a policy not to write to /usr/share/...: which is what the native installer/upgrader does in order to write the installed version number,
- is difficult to introduce 'multi-site' behavior: according to existing instructions files would need to be installed for each user wishing to use the application.

Most problems could be alleviated by storing the currently installed version number in the database instead of some file (which the webserver user (think of suexec etc.) might not be able to modify anyhow).

Like this, the native upgrade procedure (maybe even install) could be used (simplifying the packaging) as well as easy multi-site behavior would be possible at no additional cost: each DB/site would carry its own version number, which would be automatically updated if a new release is installed in the central location. The current version number of the installed files would be available from serendipity_config.inc.php and could be compared to the version in the DB.

So my proposal: why not store actual version number in database?

(PS: Yes it is true that one might to introduce some more patches to customize the compiled template and uploads directory path and such.)

----------------------------------------------------------------------

>Comment By: J.M. Roth (jmroth)
Date: 2010-04-27 09:53

Message:
Hi,

> I'm not really sure I understand this. I assume you are talking about
the
> "Shared Installation" feature specifically?

Actually, it is all intertwined. Let me write down my reasonings:

1) Having to install files for each user makes both single and shared
installs not 'nice'.

Even if you consider a single user install only, for current packaging
tools like dpkg (Debian) there is no feature to install a 'user part'
of a program (for each user), like we might know it from MSI (Windows)
etc.

2) If one wants to circumvent that, one finds out that the app version
is stored in some file that furthermore needs to be writable by the
webserver.

Even if we only consider the single user case, we still suppose the
software is installed in /usr/share (and not in his home). This one
user thus still can not write to /usr/share/... which would be
necessary to update the software. (Whatever user it is, we can say for
sure that it won't be root.)

This is the point at which I got stalled, since currently the shared
install can never work without installing at least one personal file
that has to be writable. So, currently, as far as packaging is
concerned, there would be more for the user to do, than include his
database config in some auto_prepend_file'd file, which somehow defies
the meaning of 'packaging' (which I consider making a product more or
less 'ready to use').

Generally:

To access the application I prefer setting an Alias in the webserver
configuration (instead of defining docroot to be another directory than
/var/www), thereby giving access to the relevant files in the
filesystem (while keeping the option to 'Alias' other apps to that
virtualhost) and the rest happening inside the DB. As far as the
database credentials are concerned, one can always set those using
auto_prepend_file or such.
Once these settings have been given, the ideal behavior of the app
would be to simply notice that the user/DB does not yet have
serendipity installed (or an upgrade is necessary), ask the necessary
questions, and perform it.

In order to be able to upgrade the package I have to integrate the
database update patches into some other framework. In this case
(Debian) it is dbconfig, which does not (yet) fully support shared
installations/multiple DBs for one app anyhow. This brought me to the
question of how to make s9y more compatible to handle an install (and
upgrade) itself (which then collides with the fact that the version is
stored in some text file in the file system).

> I do agree that the data in there should be as minimal as possible. But
in
> the case of installation problems, or if s9y changes the DB layer API,
it
> would be helpful to have version information outside the DB connection,
so
> that it can be modified. 

Sure, but how often does that happen? ;-)
Or if I ask the question the other way round: What does happen more
often? A new release of the software or a complete overhaul of the DB
layer API?

> Also, users for whom the upgrade failed can easily
> re-execute updates by modifying that file - for those people it would
be
> way harder to do that using possible unknown tools like phpMyAdmin for
> them?

Well I believe that someone who uses a software that stores its data
in a database should have a minimal knowledge of how to access that
database if necessary. (You are too nice ;-) )

(Ok I know the 'shared' feature is experimental anyhow... I'm just
trying to give feedback of what I feel makes sense, so consider this a
'wishlist' item)

Regards
JM


----------------------------------------------------------------------

Comment By: Garvin Hicking (garvinhicking)
Date: 2010-04-26 09:25

Message:
Hi!

I'm not really sure I understand this. I assume you are talking about the
"Shared Installation" feature specifically?

Those should always only need to write data to their own document root,
not the shared /usr/share/... directory. serendipity_config_local.inc.php
is the local version where database credentials are held, and also the
version number.

I don't see a problem with storing that data inside there, because this
file always needs to hold DB credentials, they can't really be stored
somewhere else, so having the version number inside that file instead of
instead the database doesn't seem to make a big difference for me?

I do agree that the data in there should be as minimal as possible. But in
the case of installation problems, or if s9y changes the DB layer API, it
would be helpful to have version information outside the DB connection, so
that it can be modified. Also, users for whom the upgrade failed can easily
re-execute updates by modifying that file - for those people it would be
way harder to do that using possible unknown tools like phpMyAdmin for
them?

Maxbe if you can explain a bit more, I can better understand the issue?

Regards,
Garvin

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=542822&aid=2992079&group_id=75065

------------------------------------------------------------------------------