From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from mail.fidnet.com (one.fidnet.com [216.229.64.71]) by chiba.3jane.net (Postfix) with SMTP id 19E7CABD58 for ; Thu, 18 Apr 2002 02:16:23 -0500 (CDT) Received: (qmail 21601 invoked from network); 18 Apr 2002 07:16:22 -0000 Received: from dialup-mo-28.stjames.fidnet.com (216.229.82.28) by one.fidnet.com with SMTP; 18 Apr 2002 07:16:20 -0000 Subject: Re: [gentoo-dev] ebuild question From: Tod M Neidt To: gentoo-dev@gentoo.org In-Reply-To: <1019110387.12142.46.camel@seahorse> References: <1019110387.12142.46.camel@seahorse> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 18 Apr 2002 02:15:30 -0500 Message-Id: <1019114132.3695.1336.camel@Q.neidt.net> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 963f072d-132d-4973-96c9-0ecbaaf75872 X-Archives-Hash: 21986dd88817129dd976fb34f9c33806 Hi! On Thu, 2002-04-18 at 01:13, Avi Schwartz wrote: > I am trying to create an ebuild for wingide. I have couple of problems > I trying to solve here: > > 1. The name of the archive is wingide-1.1.3-1.tar.gz. I tried to call > the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since > it thinks there are two version numbers. So I changed the name to > wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code: I would name the ebuild: wingide-1.1.3.1.ebuild You then have two options: 1. Hardcode the actual tarball name, i.e. MYP=${PN}-1.1.3-1 2. Munge ${P} for the same result, i.e. #Grab least significant version number LSV=${PV##*.) #Grab the rest MYPV=${PV%.*} #add the lsv back on MYPV=${MYPV}-${LSV} MYP=${PN}-{MYPV} There might be a more elegant munge, but that should work (although you should test it if you use it) Either way, use ${MYP} and ${MYPV} in the SRC_URI where you would normally use ${P} and ${PV}. Method number 2 (the munge) makes the ebuild version independent. SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${MYP}.tar.gz ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${MYPV}.tar etc" SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar" > > SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar" > > Is this an acceptable practice? The problem with this is that if they > come out with a -2 version, it will not be enough to rename the ebuild > file (although the bug fix files are breaking this anyway). > > BTW, PV and ${D} are not documented in the developers HOWTO. What else > is missing? Please see 'man 5 ebuild', but note that the syntax of the ebuild example is stale. Use /usr/portage/skel.ebuild as a syntax and style example. > > 2. Wingide comes with its own installation program which can be > controlled through the command line. When its archive is expanded, it > creates a wingide-1.1.3-1 directory in which there is the installation > program and the program files. Ho do I point to the installation > program? I tried the following ${WORKDIR}/${P}-1/wing-install.py, is > this correct? > > 3. The parameters it expects are the installation directory and binary > directory: > > ${WORKDIR}/${P}-1/wing-install.py \ > --winghome ${D}/usr/lib/wingide \ > --bin-dir ${D}/usr/bin > > again, does this make sense? I assume that this is in src_compile? Set S=${WORKDIR}/${MYP} When src_compile is called ${S} is the current working directory so wing-install.py \ --winghome ${D}/usr/lib/wingide \ --bin-dir ${D}/usr/bin \ || die should be sufficient (i assume you don't need an obligatory 'python' in front of wing-install.py) > > 4. Another problem I am having is that I see the following messages when > doing the install: > > >>> Install wingide-1.1.3-r1 into > /var/tmp/portage/wingide-1.1.3-r1/image/ category avi > > but when I look at the image directory I see that it didn't install a > thing Two guesses 1. you need an '=' after you flags above 2. The wing-install isn't smart enough to check if the directory exists before trying to copy which doesn't tend to work very well, might need a dodir /usr/lib/wingide dodir /usr/bin before trying to install . > > 5. The last 3 files are archives that have to be extracted over the root > installation directory which will be ${D}/usr/lib/wingide. Again, how > does one achieve this? I'm not follwing you :( Oh wait, are they patches? or something similiar > > 6. The compile stage extracts all 4 files while I realy want only the > main file to be extracted since the other 3 need to be extracted over > the installed file. Is there a way to control this? I tried to put my > own code in src_compile(), but ebuild goes ahead and extracts the > archives before executing my code Without looking at the package myself, I would just be guessing probably badly :) Ok are you talking about the other files sownloaded from SRC_URI? If so, you probably want to perform this in the src_unpack function which is executed before src_compile. again see 'man 5 ebuild' . > > 7. When the wingide archive is extracted, besides the installation > program there is another tar file extracted which containsall the files. > Another possibility for the installation of the main wingide archive is > to just extract this archive into ${D}/usr/lib. The question is, do I > have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it > for me? see above Hope that helps, tod