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
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
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.
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 on irc.freenode.net
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.
The more recent issue was discussed at:
I'll ask the user to provide for more information here.
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
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?
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
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
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.
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.
What's debian doing? Did you already have a chance to look at Debian's gallery2
If not, I'll ask Michael to forward you the patch.
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
(/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.
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.
Sure. Please post the complete gallery2 patch for FC somewhere online.
Spec file: http://www.berningeronline.net/fedora-g2/gallery2.spec
Patch0 references in spec:
htaccess file: http://www.berningeronline.net/fedora-g2/gallery2-htaccess
Apache config file: http://www.berningeronline.net/fedora-g2/gallery2-httpd-conf
Readme for Fedora package:
- g2.2 requires >= PHP 4.3.0 (such changes are mentioned in our release
G2.2 also supports DB2 and MS SQL Server too.
- echo "\$gallery->setConfig('data.gallery.base', '/srv/gallery2');" >>
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.
Better give it 24M. 16M is more like a minimum, 24M should be recommended.
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...
Putting the Gallery2 package anywhere other than /usr/share/gallery2/ would
violate the Fedora packaging guidelines:
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.