I have created ebuild files for the perforce SCM software, for p4, p4d, p4p and p4web, versions 2004.2 and 2005.1. What should I submit? only the ebuild files or also the digest files? And how would you like it, plain text or all together in a tar.gz? I know you won't be ahppy, but I renamed them: dev-util/perforce-cli -> dev-util/p4 dev-util/perforce-proxy -> dev-util/p4p dev-util/perforce-server -> dev-util/p4d BTW, what the heck is dev-util/perforce? It is p4ftpd, but why isn't this called dev-util/perforce-ftp or so? Maybe I'll add p4v (the GUI), but as I don't use it. I haven't created the ebuild files yet. tom
No, please, no digests! Just ebuild (and patches, if needed). Also, no tarballs, just plain text. See http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap2 There are also other useful docs concerning ebuilds: http://www.gentoo.org/doc/en/ebuild-submit.xml http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
files for p4: http://dbservice.com/tom/gentoo/portage/dev-util/p4/p4-2005.1.ebuild files for p4d: http://dbservice.com/tom/gentoo/portage/dev-util/p4d/p4d-2005.1.ebuild http://dbservice.com/tom/gentoo/portage/dev-util/p4d/files/p4d-2005.1/conf.d/p4d http://dbservice.com/tom/gentoo/portage/dev-util/p4d/files/p4d-2005.1/init.d/p4d files for p4p: http://dbservice.com/tom/gentoo/portage/dev-util/p4p/p4p-2005.1.ebuild http://dbservice.com/tom/gentoo/portage/dev-util/p4p/files/p4p-2005.1/conf.d/p4p http://dbservice.com/tom/gentoo/portage/dev-util/p4p/files/p4p-2005.1/init.d/p4p files for p4web: http://dbservice.com/tom/gentoo/portage/dev-util/p4web/p4d-2005.1.ebuild http://dbservice.com/tom/gentoo/portage/dev-util/p4web/files/p4web-2005.1/conf.d/p4web http://dbservice.com/tom/gentoo/portage/dev-util/p4web/files/p4web-2005.1/init.d/p4web I hope this is ok so..
Some progress with this ebuidls ?
I'm working on a solution how to handle multiple architestures in the ebuild. I've been in contact with perforce as well as the portage developers. I havent recieved any reply from perforce so far, maybe I should ping them to find out the status of my request. I don't know why my ebuilds havent been accepted, but I'm planing to rewrite them and repost. But this is low priority since I don't have much time so don't expect any updates in the next weeks or months. There is a bug report related to the perforce ebuilds, http://bugs.gentoo.org/show_bug.cgi?id=115016
Created attachment 82051 [details] Perforce CLI ebuild for 2005.2
Created attachment 82052 [details] Perforce GUI ebuild for 2005.2
Created attachment 82054 [details] Python perforce API ebuild for 2005.2 version of p4api.tar
The perforce-cli and perforce-gui ebuilds from Mark Charlebois works fine for me.
I'm no longer maintaining this package. No-one else has stepped up and volunteered to maintain this package. We will be removing it from Portage shortly. Best regards, Stu
I would be really sorry to loose perforce. I'm using it on a daily basis, both private and at work. The latest perforce versions work perfectly, and the only issue I can see is the digest collisions. I would have been happy to maintain the package if had developer status... Is it hope for the perforce ebuilds if I could find a solution to the digest problems?
Hi Havard, If you'd like to become a developer, to maintain the Perforce packages, that's definitely possible. Please drop by in #gentoo-php on irc.freenode.net, and let's chat further about it. Best regards, Stu
> If you'd like to become a developer, to maintain the Perforce packages, that's > definitely possible. Please drop by in #gentoo-php on irc.freenode.net, and > let's chat further about it. Is anybody in charge of the perforce ebuild? I'm really interested in having this in gentoo. I'm currently in the process of becoming a x86 arch tester so becoming a developer for this is not possible at this moment. But I can try to write ebuild for the new versions. I administer a perforce server in my work so I think I can be useful for this task.
(In reply to comment #11) > Hi Havard, > > If you'd like to become a developer, to maintain the Perforce packages, that's > definitely possible. Please drop by in #gentoo-php on irc.freenode.net, and > let's chat further about it. > > Best regards, > Stu > I'd be interested in maintaining the perforce client ebuilds for p4, p4v and the python API. I do not run the perforce server (I just connect to one at work) so I wouldn't be able to maintain the perforce server ebuilds. At least not until I could become familiar with them.
Created attachment 95769 [details] ebuild for p4 command line client 2006.1
Hi Mark. I would be happy if you or anybody else implemented (and maintained) a solution for the perforce ebuilds. The major obstacle as I see it is this: Different versions of perforce will download binaries with the exact same name. For instance will the perforce client version 2005.2 and version 2006.1 both download a binary called 'p4'. This will create problems such as digest collisions between ebuilds and failing digests if you try to upgrade your perforce client and the old version is still in you distdir. If you, like I've done myself many times, try to avoid this problem by doing an 'ebuild digest', you could end up with a broken p4 binary and brake your p4 repository. The solution such as I see it, is enabling an extended syntax in the ebuild such as: SRC_URI="<path-to-p4-binary>/p4 => p4-${PV}" which should download the p4 binary but saving it under the name p4-${PV}. I tried to implement this myself, but hacking portage wasn't done in an evening, and I haven't had the time to sit down and implement this since. Again: I would be happy if anyone solved this.
> Again: I would be happy if anyone solved this. I am currently working in the ebuild of the 2006.1 server version. To solve the problem you say, couldn't the perforce binaries stored in other repository with the proper renaming applied?
> The solution such as I see it, is enabling an extended syntax in the ebuild > such as: > SRC_URI="<path-to-p4-binary>/p4 => p4-${PV}" This is really nice. In comment #4 I described my problem but nobody was able to help me, so I guess it's a new feature. I also think this is the right way to go, I don't know if storing binary files in the portage repository is allowed, and now that it's possible to download files and rename them in the distfiles directory, it's even easier for the ebuild maintainer to maintain or create new euilds. But.. I'm not working with perforce anymore, so don't expect any updates from me... Oh, maybe it's worth reopening the bug again now that someone is writing new ebuilds ;)
(In reply to comment #17) > I also think this is the right way to go, I don't know if storing binary files > in the portage repository is allowed, and now that it's possible to download > files and rename them in the distfiles directory, it's even easier for the > ebuild maintainer to maintain or create new euilds. Clearly, downloading + renaming is the way to go. But I think it is not allowed. Storing binaries in the portage repository is not a good idea. I was thinking in Gentoo Mirrors or other mirrors. And yes, we should open a new bug, this is marked as resolved. :) Gentoo mirrors
No, currently there's no way of renaming a downloaded file in portage. The extended ebuild syntax is just my suggestion of how portage could support this. We would have to make changes to portage to actually get it to work. And those changes aren't trivial.
I have created bug #146436 for new perforce client ebuilds. I also attached a new ebuild for 2006.1 that names the executable p4-${PV} as proposed.
