I created a new ebuild for installing PostNuke (http://www.postnuke.com/) and automating database setup. This ebuild depends on php and mysql. This is my first attempt at creating an ebuild, but it seems to work great for me. I'd like to submit it for further testing and possible inclusion in portage. Thanks.
Where's the ebuild?
Hmm... I don't seem to be able to add an attachment to this bug. I created a tgz file containing the .ebuild and support files, clicked Create a New Attachment, selected the .tgz file, filled out the Summary and Description, and clicked Submit. What am I doing wrong? Thanks.
Created attachment 23960 [details] postnuke ebuild PostNuke ebuild submitted for Jared because bugzilla doesn't seem to like him
Sent to the wrong herd. Belongs to web-apps. Re-assigning before Tal does ;-) Stu
Hi, Sorry for the delay in replying. We've been very busy putting a new framework in place for ebuilds for web-based applications. This has now been added to Portage. We need you to update your ebuild to use the new framework before we can accept your ebuild. Please emerge net-www/webapp-config (make sure you get version 1.2 or later), and update your ebuild to work with this new tool. You can use 'man 5 webapp.eclass', 'man 5 webapp-config' and 'man 8 webapp-config' to learn more about how your ebuild needs to work. You can find an example ebuild, for phpmyadmin, in /usr/share/doc/webapp-config-1.2/ If you encounter any difficulties with the new framework (and we apologise, but there are sure to be a few at first), please let us know and we'll do our best to help you. Best regards, Stu
Created attachment 47779 [details] PostNuke-0.750.ebuild This is my version of a PostNuke ebuild. it is fully compliant with webapp-config. You need php and mysql for it to work. with ebuild PostNuke-0.750.ebuild config you can create a database. I copied this part from the mambo ebuild.
Anything happening with this..? Registered interest here!
Sure I'm interested :) Since I'm on the core-dev list of Postnuke, I'd even be happy to maintain the ebuild.
This software is full of vulnerabilities - it's by far worse than phpbb - so I might think the webapp herders should say WONT in light of the removal of phpbb.
(In reply to comment #9) > This software is full of vulnerabilities - it's by far worse than phpbb - so I > might think the webapp herders should say WONT in light of the removal of phpbb. It is? I'm in development team of Postnuke itself. It'd be nice if you would share such information. Knowing the code, I can't imagine it containing more than any other like.. hmm let's say.. phpbb? I don't see your argument as any valid for denying it to the portage tree. The ebuild not being compatible with webapp-config however seems more logical to me. Should there be any interessed people, I'd be happy to convert it.
(In reply to comment #10) > It is? I'm in development team of Postnuke itself. It'd be nice if you would > share such information. I meant problems
(In reply to comment #10) > It is? I'm in development team of Postnuke itself. It'd be nice if you would > share such information. I meant problems¹ in the past and what to expect for the future when you extrapolate. > Knowing the code, I can't imagine it containing more than any other like.. PostNuke has one of the most bad names in regards to security among open source projects, I know of. > I don't see your argument as any valid for denying it to the portage tree. That's not up to me. [1] http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=postnuke
And phpbb isn't? Anyway this is not the place to discuss this (The forums would more ideal) but I admit the code hasn't always been what it should have been. All the issues in the above link are fixed in the latest version 0.761, btw.
In the early days, PostNuke was a fork of PHP-Nuke, and so it suffered a great deal from PHP Nuke problems. Since the early days, PostNuke's core has been completely rewritten, and the program is much more secure. If you look closely at the bug reports, all the security advisories correspond to the only bits of PHP Nuke code left in the distribution. In the next version, these bits of code disappear too, and PostNuke becomes a package wholly unrelated to PostNuke and rebuilt from the ground up. That is undisputable. The future is bright for PostNuke, and you shouldn't be biased about a product simply because it's name links it to one of the worst CMS programs out there.
(In reply to comment #13) > unrelated to phpNuke Minor typo, I guess?
*** Bug 107891 has been marked as a duplicate of this bug. ***
I had created a new bugreport for the latest version. I'll add the ebuild here as well then
Created attachment 69721 [details] Postnuke 0.761 ebuild
Why isn't this in the portage tree?
Please note if you are using safe_mode, webapp-config may install PostNuke into a nonworkable state. Please see bug http://bugs.gentoo.org/show_bug.cgi?id=112114 for more details.
The reason for this appears simply that this ebuild is broken. Safe mode requires that files a php script file acts on has the same ownership as the script file itself. For example, pnRender_compiled directory is owned by apache, but the script files acting on it are owned by root. This does not work in safe mode. This could be fixed if the server-owned-files are reclaimed by root and the permissions are set to 777. pnTemp must also be included in the list of server-owned-files. Alternatively, it could be fixed by making all of PostNuke and all the installed files owned by the webserver.
Why is phoenix-sql in its own directory?
We are not interested in maintaining this or any other phpnuke clone/fork, even in the overlay. Sorry. WONTFIX.
