Bug 238560 - Cannot Install Due To Incorrect Hardcoded Changes vs. Upstream (e.g. /srv/ path)
Cannot Install Due To Incorrect Hardcoded Changes vs. Upstream (e.g. /srv/ path)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gallery2 (Show other bugs)
6
All Linux
medium Severity high
: ---
: ---
Assigned To: John Berninger
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-01 09:57 EDT by Andy Staudacher
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-07 11:11:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andy Staudacher 2007-05-01 09:57:52 EDT
Description of problem:
The gallery2 source-code of the gallery2 package for FC seems to be patched by
its FC package maintainer. Paths that should be determined dynamically at
runtime during the web-based installation of gallery2 have been hardcoded in the
FC version of gallery2.

Due to these changes, I have heard of at least 2 users trying to install
gallery2 on FC without success.

The hardcoded path "/srv/" obviously doesn't work for everyone.
I suggest that the FC patch against the original gallery2 source code is removed
or at least reviewed. It seems that it only applies to a specific setup and not
to all FC setups.

Personally, I don't use FC and I thus can't reproduce the problem.
In my function as gallery2 developer, I've asked one of the FC users to report
that issue to the FC package maintainer for gallery2, but nothing seems to have
happened.

Steps to Reproduce:
1. Fetch gallery2 with FC's package management tool
2. Browse to http://localhost/ ... gallery2/install/index.php in your web-browser
3. Try to pass the authentication step of the installer
  
Actual results:
Gallery 2 can't locate the login.txt that the user creates in the gallery2 folder.
Because of the hardcoded /srv/ path, Gallery 2 looks in the wrong location.

Expected results:
Gallery 2 dynamically determines the location of the gallery2 folder with
dirname(dirname(dirname(__FILE__))) and thus can find the user's login.txt file
and the user can successfully authenticate.

For questions, don't hesitate to contact us at:
- gallery-devel@lists.sourceforge.net
- #gallery on irc.freenode.net
- http://gallery.menalto.com

Thanks!
Comment 1 John Berninger 2007-05-01 12:13:21 EDT
I'd be happy to look at this, but I need more information on the environments in
question.  The patch in question was made to comply with the requirement that
the package work with a read-only /usr, and the default location for the
login.txt and data store would then be /usr/share/gallery2 which conflicts with
/usr ro.  I've installed the Fedora version of Gallery on FC4, 5, and 6 and had
it work out of the box, with the appropriate files placed where the installer
tells the user to place them.  If you can get your users to provide specifics on
their environments in this report, I'll certainly look at them and do my best to
resolve them, but for now I'm setting this NEEDINFO.
Comment 2 Andy Staudacher 2007-05-01 12:25:13 EDT
Thanks!
The more recent issue was discussed at:
http://gallery.menalto.com/node/64015

I'll ask the user to provide for more information here.

BTW:
login.txt must be written / created by the user through the command line. It
does not need to be writeable.
Thus I don't quite understand why having login.txt in
/usr/share/gallery2/login.txt would be a problem.

I guess FC's policies are not that different from Debian's policies. I'd be glad
to ask the Debian package maintainer to join this discussion if that would help.
He's also involved in the Gallery project and is thus in close contact with the
Gallery developers.
Comment 3 John Berninger 2007-05-01 12:46:41 EDT
login.txt doesn't need to be writable, but if /usr is ro then
/usr/share/gallery2/login.txt can't be created.  I agree that my patch isn't
ideal - far from it - but I hesitate to agree with 'buggy'.  Is there an easier
way to tell Gallery2 to look in a different default for login.txt and dynamic
data, other than the Gallery installation directory?
Comment 4 Andy Staudacher 2007-05-01 17:51:08 EDT
It's hard for our support team to support gallery2 distributions that have
changes that they're not aware of. Thus, we'd be glad to see if the gallery2
package in RH / FC didn't have any patches. That's my motivation to see the
patch gone.
There are other distributions with changes. So as long as we know exactly what
has been changed in what way, it's fine (just supoptimal).

@Alternative locations for login.txt:
We haven't any hooks to change the login.txt location easily.
Also note that a few other emergency features in G2 rely on the same login.txt
location.

@/usr read-only:
It's unfortunate, but how often is a non super-user actually installing gallery2
on FC? That is, a user that can't sudo / su?

I'll ping our Debian maintainer to see how they solved this.

Thanks.
Comment 5 John Berninger 2007-05-03 12:09:44 EDT
OK, I've gotten things to work with symlinks from /usr/share/gallery2 into
/etc/gallery2 (login.txt and conig.php), but there remains the problem of the
installer steps (specifically, steps 3 and 4) referencing /usr/share/gallery2
where I'd like them to reference /srv/gallery2.  These references, as far as I
can determine, are in install/steps/MultisiteStep.class and
install/steps/AuthenticateStep.class.  Is there any way to change these items to
reflect data paths of /srv/gallery2, or something detemrined by a config file? 
Putting "$gallery->setConfig('data.gallery.base', '/srv/gallery2');" in
config.php has no effect on the installer steps, unfortunately.
Comment 6 Andy Staudacher 2007-05-03 12:39:16 EDT
What's debian doing? Did you already have a chance to look at Debian's gallery2
package patch?
If not, I'll ask Michael to forward you the patch.
Comment 7 John Berninger 2007-05-03 13:09:21 EDT
I've looked at the debian patch, and he's changing a path in config.php to point
to the new directory.  Specifically, he's doing
s/\/usr\/share\/gallery2\/g2data/\/var\/lib\/gallery2\/g2data/
(/usr/share/gallery2/g2data -> /var/lib/galler2/g2data).  However, in the
distribution, there's nothing in config.php that references the Gallery install
directory (/usr/share/gallery2) prior to running through the installer - at
least in the Fedora version.  I'm going to try taking a new snapshot from SVN
(the one I'm using is from Aug of last year), but given where the issue is
coming in, I'm not sure it'll help.
Comment 8 John Berninger 2007-05-07 07:44:03 EDT
OK, things look a little better after updating to a 2.2 branch snapshot.  The
hardcoded paths are gone, and it's putting /srv/gallery2 where I wanted it to. 
Still some stuff that I think could be done better than I've done currently -
poke the README.fedora for the specifics on whats 'different' between my package
and upstream - but it seems a lot better than it was.  If you have some spare
bandwidth to give it a once-over, please do - it worked as expected for me, but
I'd like a second opinion anyway.
Comment 9 Andy Staudacher 2007-05-07 09:58:35 EDT
Sure. Please post the complete gallery2 patch for FC somewhere online.
Comment 11 Andy Staudacher 2007-05-07 10:42:36 EDT
@spec:
- g2.2 requires >= PHP 4.3.0 (such changes are mentioned in our release
announcements)

- %description
G2.2 also supports DB2 and MS SQL Server too.

- echo "\$gallery->setConfig('data.gallery.base', '/srv/gallery2');" >>
${RPM_BUILD_ROOT}%{g2confdir}/config.php

1. You don't want to hardcode /srv/gallery2 there if you define $g2datadir at
the top of the script
2. g2datadir needs a trailing slash.

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

@htaccess:
Better give it 24M. 16M is more like a minimum, 24M should be recommended.

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

@README:
G2.2 also supports DB2 and MS SQL Server too.

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

I still see a major problem with this setup though.
G2.2 has downloadable plugins. "Site Admin -> Plugins -> Get More Plugins"
Since you can't write to modules/ and themes/ in this setup, that feature won't
work at all in FC.
That's quite disappointing since users can't get the latest plugins that way.
Not all plugins that you can get via downloadable plugins are official ones. So
they can't get them via FC's package management either.

Is it no option to put the gallery2/ folder into /var/... somewhere in the webroot?

If there's no obvious solution to that, I suggest you add a known issue in your
README about downloadable plugins and close this bug for now...

Thanks
Comment 12 John Berninger 2007-05-07 11:11:25 EDT
Putting the Gallery2 package anywhere other than /usr/share/gallery2/ would
violate the Fedora packaging guidelines:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-5d1681fa7cf3714ad490fbf7c095a0cfe16da27f

Additionally, this would result in the new themes and modules not being managed
by RPM or present in the RPM database, which while I'm aware isn't an issue for
upstream, is somewhat of a Bad Idea for Fedora folks.  Thus, I'm taking your
suggested 'Known issue, not gonna work' route for this one.  The other issues
have been corrected and I'm about to request new builds for FC-5, FC-6, and
devel (what will be F7).

If you have other comments / concerns, please feel free to open a new bug,
reopen this one, or just contact me via email.  I try to keep up with the
gallery2 announce and devel lists, but can't always keep as current as I'd
prefer with all the other lists I have to sort through.

Note You need to log in before you can comment on or make changes to this bug.