Mark Charlebois has offered to maintain the perforce client ebuilds. New ebuilds will be posted here as the previous bug has been closed.
*** Bug 146461 has been marked as a duplicate of this bug. ***
Created attachment 96113 [details] perforce-cli ebuild (2006.1) This ebuild names the executable p4-${PV} so it does not collide with other versions.
This bug carries on from #93828 which is now closed.
Created attachment 96116 [details] perforce-gui ebuild 2006.1 Adds the version suffix to the p4v binary and the instalation directory for the help files.
Created attachment 96117 [details] perforce-gui ebuild 2006.1 (minus the cruft)
Created attachment 96118 [details] p4python ebuild 2006.1
Created attachment 96132 [details] perforce-server ebuild (2006.1) My first approach to the ebuild server. Things I am working on: - Create a /etc/conf.d/p4 for variables like: port, logfile, journal file - Create a logrotate file for the log - Create a cron job for creating checkpoing (disabled by default)
Created attachment 96133 [details] files\p4d
(In reply to comment #7) > Created an attachment (id=96132) [edit] > perforce-server ebuild (2006.1) > > My first approach to the ebuild server. Things I am working on: > > - Create a /etc/conf.d/p4 for variables like: port, logfile, journal file > - Create a logrotate file for the log > - Create a cron job for creating checkpoing (disabled by default) > In the following code, shouldn't p4d be p4d-${PV} ? src_install() { dosbin ${DISTDIR}/p4d exeinto /etc/init.d doexe ${FILESDIR}/p4d }
These ebuilds still have the problems I explained in bug #93828. Different versions of p4 will be downloaded with the same filename into ${DISTDIR} giving digest conflicts and possibly corrupted binaries. I don't think installing p4 with a different name, p4-${PV}, solves any problem. There should always be only one p4 binary installed. p4 should be downloaded and stored in ${DISTDIR} as p4-${PV}, and then renamed to p4 when installed.
Not a recruiters bug, bouncing to bug-wranglers. You need to find a mentor that can open a proper new-dev bug if you want to become a developer.
(In reply to comment #10) > These ebuilds still have the problems I explained in bug #93828. Different > versions of p4 will be downloaded with the same filename into ${DISTDIR} giving > digest conflicts and possibly corrupted binaries. > > I don't think installing p4 with a different name, p4-${PV}, solves any > problem. There should always be only one p4 binary installed. p4 should be > downloaded and stored in ${DISTDIR} as p4-${PV}, and then renamed to p4 when > installed. > Ah! I totally misunderstood your previous comment. I see what you mean now. I'll see if I can host the renamed binaries somewhere and I'll remove the ${PV} from the installed binary's name.
Created attachment 96184 [details] perforce-cli ebuild (2006.1) with fetch restriction This version of the ebuild forces the user to download the p4 binary and rename it with the version extension.
Created attachment 96187 [details] perforce-cli ebuild (2006.1) with fetch restriction Fixed comment for download URL
Created attachment 96188 [details] perforce-gui ebuild 2006.1 with fetch restriction
Created attachment 96221 [details] perforce-server ebuild (2006.1) perforce-gui ebuild 2006.1 with fetch restriction and conf.d/p4d file support
Created attachment 96222 [details] files\p4d.initd
Created attachment 96223 [details] files\p4d.confd
H
Håvard, How should we proceed about having this bug assigned to a developer and in the longer term becoming developers to maintain the client and server ebuilds? - Mark
I'm not entirely sure, but take a look at comment 11 in bug #93828. Maybe you should try to contact this guy and see if he could review your ebuilds?
Created attachment 226221 [details] Portage overlay for server, GUI and CLI This overlay was tested with Perforce 2009.2, GUI (P4V) build 2362331 and server/CLI build 238357. I haven't tested it extensively but I thought I'd share it anyway for those who are still interested in Perforce on Gentoo. Thanks to the other contributors of this bug for the original ebuilds that I based this on! Usage: 1. su to become root. 2. Untar this in /usr/local/portage (it unpacks to a directory "p4"). 3. Add perforce-server, perforce-gui and perforce-cli to your /etc/portage/package.keywords file (alternatively, use ACCEPT_KEYWORDS=~x86 on emerge). 4. emerge perforce-server and/or perforce-gui and/or perforce-cli as needed. Note, the ebuilds will tell you where to download the files and how to rename them. Unfortunately Perforce doesn't use the version in the file name which is a problem when using Portage.
Oops I forgot you also need to add this to your /etc/make.conf: PORTDIR_OVERLAY=/usr/local/portage/p4
(In reply to comment #22) > Note, the ebuilds will tell you where to download the files and how to rename > them. Unfortunately Perforce doesn't use the version in the file name which is > a problem when using Portage. You could use arrows to change names on the fly instead, see the Package Manager Specification [1] section 9.2.7 and table 9.1. Look for an example in the app-admin/rudy ebuild. You can also check for the arch (see an example in the app-admin/flexlm ebuild) to be able to install for amd64 too, as that's what most people run nowadays. If you're interested I could proxy-maintain that for you. Denis. [1] http://distfiles.gentoo.org/distfiles/pms-3.pdf
Created attachment 238265 [details] Improved overlay for Perforce server, CLI client and GUI client (P4V) Thanks for the remarks about using the arrow on SRC_URI. I changed the EAPI on each ebuild to 2 and used the arrow to automate the downloading. I didn't implement x64 because I'm running a 32 bit Gentoo but it shouldn't be very hard to do: the only change that should be made for x64 compatibility is the download location: ...bin.linux26x64... instead of ...bin.linux26x86... The ebuilds should now be version-independent for any version later than 2000: if you want to install another version simply copy the ebuild to the version you're interested in and do e.g. ebuild perforce-server-2005.1.ebuild digest, then emerge your version as usual. If this would ever go into the main repository, keep in mind that there's a potential problem with updating servers: the updated server will update the database and there's no way to downgrade the server because an older server will not recognize the database. This is an issue if you're using a license file with an expiration date earlier than the server version you're installing: the new server will be happy to update the database but then it won't be able to log anyone in because it sees the expired license. I couldn't think of an easy way to prevent this from happening e.g. in case of a world update. Which brings me to another issue: when you do a revdep-rebuild, it may detect that the GUI needs updated libraries so it will re-emerge perforce-gui which (obviously) doesn't install the later libraries. The program will know where to get its libraries and it will keep working fine, it's just that revdep-rebuild will always think it's out of date. That's a minor nuisance that I'm willing to live with.
Created attachment 255071 [details] Overlay with support for amd64 I modified Jac's excellent ebuilds to add support for amd64. These should work on both x86 and amd64.
Created attachment 256928 [details] Improved overlay for Perforce server (P4D), CLI Client (P4) and GUI client (P4V) This overlay fixes the problem that a revdep-rebuild would always try to rebuild p4v. It does this by installing a file into the /etc/revdep-rebuild directory. I incorporated Jose Quinteiro's improvements for x64 support. Thanks Jose! I also updated the Perforce build numbers to those of the current release: 2010.1.271261 (p4v), 2010.1.265509 (p4) and 2010.1.273938 (p4d). The Perforce people unfortunately have a nasty habit of not using the patch level in their file names so if you run into checksum errors when you emerge anything from this overlay, it's because Perforce updated their stuff; you will just have to rename the ebuilds to the current patch level, generate a manifest with the ebuild(1) command, and then do the emerge again. To use this: - Use su to become root - If you installed one of the previous overlays, delete it - Unpack the tarball in /usr/local/portage - Add /usr/local/portage/p4 to the PORTDIR_OVERLAY definition in your /etc/make.conf (e.g. PORTDIR_OVERLAY="/usr/local/portage/p4") - Unmask the dev-vcs/perforce-server, dev-vcs/perforce-cli and dev-vcs/perforce-gui e.g. by adding their names to the /etc/portage/package.keywords file - Emerge the package(s) that you need. Enjoy!
Created attachment 257525 [details] Improved overlay for Perforce server (P4D), CLI Client (P4) and GUI client (P4V) This patch updates p4v to the latest version (2010.1.276058) and adds an icon for P4V to the menu. See previous entries for instructions on how to install. Please note, because Perforce doesn't make downloads available with the full patch version in the name, the ebuild will stop working as soon as the Perforce people update their software. If emerge fails with a file size mismatch or checksum error, it probably just means Perforce updated their software. You will need to rename the ebuilds to match the updated version and then run ebuild(1) to update the manifest. Don't update the manifest without renaming the ebuild; if you do, Portage will think you are using a different version than you actually are using.
I've added Jac's latest changes to my user overlay: http://git.overlays.gentoo.org/gitweb/?p=user/JoseQ.git;a=summary Please note that because of Perforce's lame non-versioning you may get manifest errors unless you rm /usr/portage/distfiles/perforce-* before re-emerging.
(In reply to comment #29) > Please note that because of Perforce's lame non-versioning you may get manifest > errors unless you rm /usr/portage/distfiles/perforce-* before re-emerging. To clarify this: if you get a manifest error, it probably means that Perforce has updated their files. Since they don't update their file names, Portage has no way of detecting whether this happened or whether something went wrong during the download. My brain is too deep into other stuff to know what it means to do the rm as Jose proposes, but if you re-generate the manifest without renaming the ebuild files, you are basically telling Portage: "Oh wait, I said version XXX has checksum CCC but it has checksum DDD". What you really want to do is tell Portage "Okay, I said version XXX has checksum CCC but now there's a NEW version with checksum DDD" so that it knows that what you have installed is out of date. Bottom line: If you run into the problem that the manifest is incorrect, you should rename the ebuilds as well as generate new manifests. I asked Perforce if they could add the version number to the downloaded file or path but their answer was basically: "This is what works for us". Too bad, because I think the file name problem prevents Perforce from ever becoming part of the main Portage tree.
(In reply to comment #30) I had already installed these ebuilds. Portage detected that I already had the tarballs in /usr/portage/distfiles, and did not try to download them again. Since I'd made the manifest against the latest from the Perforce site, the manifest check failed against the old tarballs. Everything should work fine as long as you use the latest tarballs with these ebuilds.
There seems to be an overlay here: https://github.com/VladRassokhin/perforce-overlay (I'm not the owner). I found a few ebuilds in random overlays as well.
