From owner-freebsd-ports@FreeBSD.ORG Sat Aug 3 02:00:05 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC8917A4; Sat, 3 Aug 2013 02:00:05 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9846522F8; Sat, 3 Aug 2013 02:00:05 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id er7so2401328obc.17 for ; Fri, 02 Aug 2013 19:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D0Tn3hnMXQKmWEZCe+O6/KZVEJM60qTdVnH96KHnBEI=; b=hz32eCAnKIpJYSqpMxUbdJMPnHPrLY71FIwRRCrEzUQ/TVSSg2+wUdCbBdRA19dwUk 8BiRjSzwqzDBXpJeGjKj7wgOR5vdFJKLY9Y52oPEJXMaVfAQliErmUK3C0/yHcTWibFq Q88fviORCSB26JMXfx+szPtGoADO49A/Tzjx+JPnTkme+0mI4IJ3jK3ARf16Fs1CQK92 nD209Db9kPEYwhF/snBiXQf9LNsfFlM5AuZx1mew8QdeChIDTUdKr9TReB5PIk4VNo8O Hh/jN4sg5eBwgkPj3GoHIcE8LWcKd2x1CR/pjbxl5WI1m7l/uVYlrK/R3APD32BxHd5G sYzQ== MIME-Version: 1.0 X-Received: by 10.182.61.52 with SMTP id m20mr4075700obr.38.1375495204820; Fri, 02 Aug 2013 19:00:04 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.245.133 with HTTP; Fri, 2 Aug 2013 19:00:04 -0700 (PDT) In-Reply-To: <51FAD121.4060104@gmail.com> References: <20130227132633.GI16178@ithaqua.etoilebsd.net> <51C9E5A4.2060502@gmail.com> <51F51F99.6080502@gmail.com> <51F5226B.4030206@marino.st> <51F809D5.80705@gmail.com> <51F94BA6.5020308@gmail.com> <51FAD121.4060104@gmail.com> Date: Sat, 3 Aug 2013 03:00:04 +0100 X-Google-Sender-Auth: _OHo5vCOi-hL7BeNPr9wKRY5bR8 Message-ID: Subject: Re: Ocaml ports needs love From: Gabor Pali To: Michael Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: marino@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 02:00:05 -0000 On Thu, Aug 1, 2013 at 10:20 PM, Michael wrote: > from the standpoint of a system administrator having two sets A and > B of software packages managed by two different tools has a lot of > drawbacks: I am fully aware of all the issues you have summarized as I have been maintaining the Haskell Cabal ports for the last 4-5 years, whose number in the ports tree slowly exceeds 400 these days :-) > I picture myself something like > having an opam.bsd.mk makefile delegating all its work to opam, as in: > > do-build: > ${CD} ${WRKSRC} opam build ${OPAMPACKAGENAME} OPAM only has an "install" subcommand which is the build and the install phase together. On the other hand, I do not think that OPAM could work with standalone packages. It has to have a package index where it stores all the metadata (i.e. the OPAM package and compiler descriptions), but packages are still served via the regular OCaml build solutions, such as OASIS. As I wrote in my previous mail, OPAM is much like the reincarnation of the ports tree itself in OCaml land. > =97 OPAM manages its =93own file hierarchy=94 and does not install binari= es > and so on at the regular places (I only glimpsed at this, tough). It puts binaries under its own ".opam" state directory, depending on which compiler is used. Note that because OPAM supports using multiple different OCaml compilers (and switching between them), personally I see it hard (if not impossible) to integrate with the practices of the FreeBSD ports. > A quick fix for this could be to have a dedicated installation, say > something like =93OPAMROOT=3D/usr/local/opam=94 and adding the relevant > locations to the path (binaries and dll). OPAM uses the "config env" subcommand to set all the relevant environment variables for the currently used compiler toolchain, like it sets the PATH each time, so the corresponding binaries are used to build the packages. Bringing this to the level of the system (i.e. prepend the OPAM directories to the system-level PATH value) might not be the best solution. Note that what FreeBSD ports would require is actually the build "recipe", most of the other things can be then derived. So, we could utilize the OPAM package descriptions to generate FreeBSD ports but not OPAM itself. > =97 OPAM does not distinguish between build and install while FreeBSD > ports do. Yes, it does not, see above. > I think this is mostly a security issue: building does not require > elevated privileges, only installing does. To support this separation, > we would need to tweak OPAM for FreeBSD. OPAM is indeed missing the separate "install" target in its package description. I have not managed yet to learn why this design choice was made... > =97 We need to generate pkg-plist or extract an installation script or an= y > similar information from an OPAM package. > > =97 We need to extract tarball location, dependancy information and > descriptions from OPAM packages. Been there, done that. For the Haskell Cabal ports, I have such a tool, called hsporter [1] (which can also help with updating, by the way). > BTW I have a port for ocaml-4.00.1 (PR ports/173364) which still has a > small issue =97 because other ports install docs in > '/usr/local/share/doc/ocaml' , the directory will not be cleanly > removed. What ports? Other OCam ports (that depend on lang/ocaml)? Have you tried @dirrmtry instead of @dirrm in the pkg-plist? [1] https://github.com/freebsd-haskell/hsporter