From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 06:40:56 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C521FFF2; Wed, 26 Jun 2013 06:40:56 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 0B990112E; Wed, 26 Jun 2013 06:40:55 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w59so10068267wes.10 for ; Tue, 25 Jun 2013 23:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=w958lv0Ev0d8U1P5b5AsXMe+jl5iqiQuhC5uocmvQak=; b=ixiXIeMPZoA60ErlJJDItZ5EfSnU16HkNf7GEmAnoZjYXZG/BmqOk9MzzZIXF1Xtos +nw7cdiMVBSfsfougtdQiz5b72lKu5GSUVpzhIKQYUCGEmso2yQEv7a5Sirp8Vh0qCUw n8q2irfWJKXUtaDADs4716dGcgZ5pzm8vRG87JRWOWSF0xgKC4pFVk9Gk0ICKoDiNUtd 8vXXOxxQvCU41sQMnc4J8YK8rjjOgM5pD5r2EnW5SrXqOHwMaPxZCpRqTVelrN9dX0pC WIxoOguITCuPGK92M4+88J+bN7kSfMBGnsWrkIjVTcoHLBGMmF8c25Nq/56m8uSAbKhA Js5g== X-Received: by 10.180.85.35 with SMTP id e3mr1564808wiz.30.1372228855231; Tue, 25 Jun 2013 23:40:55 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id u9sm8625370wif.6.2013.06.25.23.40.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 23:40:54 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 26 Jun 2013 08:40:52 +0200 From: Baptiste Daroussin To: Jeremy Chadwick Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626064051.GG93612@ithaqua.etoilebsd.net> References: <20130626001406.GA63314@icarus.home.lan> <20130626061219.GA68398@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qxfKREH7IwbezJ+T" Content-Disposition: inline In-Reply-To: <20130626061219.GA68398@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, freebsd-ports@freebsd.org, Andrej Zverev 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: Wed, 26 Jun 2013 06:40:56 -0000 --qxfKREH7IwbezJ+T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: > On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: > > Hello, and first please accept my apologies for this situation. >=20 > Understood, I just hope this can get addressed/fixed sooner than later, > because what we have right now is reproducible breakage. :-) >=20 > > > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > > > svn up /usr/ports > > > cd /usr/ports/whatever/p5-whatever > > > make install > > > pkg_delete p5-whatever > >=20 > > As I know we are never supported mixing of ports and packages. > > If you initially installed something from package and decide to use > > ports in this case better to rebuild all or stay with packages. >=20 > And here is where you are sadly mistaken. While I cannot find any sort > of official statement on the "mixing of the two", the fact of the matter > is (and possibly you did not know this -- I'm not sure) that packages > are built **from** ports ("make package" does the magic). This is > confirmed as well: >=20 > http://www.freebsd.org/ports/index.html > http://www.freebsd.org/doc/en/articles/linux-users/software.html >=20 > Please be aware when I say "package" I am talking about the .tbz balls > utilised by the base system's pkg_* tools (not pkg(8)) and used by the > OS installer and so on. For pkg(8) I believe poudriere is used to make > the packages. I don't use/can't speak about pkg(8) et al. Wrong and totally wrong, the way the ports tree works with pkg(8) is exactl= y the same way it works with pkg_install (make package does the same). poudriere is just some script to make sure everything is done in the right order, cleanly and works transparently with both pkg(8) and pkg_install. >=20 > For both pkg_* tools and ports, both use the same default base path > (/usr/local), **and** both register their bits in /var/db/pkg. Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the packa= ge tool to register a package may that be pkg_install or pkg(8) this tool will register the package where ever it seems suitable to itself meaning /var/db= /pkg in the case of both pkg(8) and pkg_install. >=20 > Package installation does not utilise any part of the ports/Mk/* > framework, but that isn't anything new -- it's been like that since at > least the 2.2.x days, possibly earlier. >=20 > So in summary, when making changes to ports/Mk/*, you really have to > think about the combination of the two, and make sure you don't break > anything when changing key pieces of those framework bits. That is exactly what has been done in the case of the change. >=20 > > > What I'd like to know: > > > > > > - Why the major.minor.patchlevel --> major.minor path change in the > > > first place. I have never, ever seen this done anywhere on any *IX > > > system I've used. Where's the justification? Was this discussed on > > > some perl mailing list somewhere as a "new and better way"? It's > > > essentially saying "x.y.z is always going to be compatible with x.y.z= +1" > > > which is not true (particularly with XS, as I understand it). Where > > > was this discussed publicly? > >=20 > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D26605+0+archive/2013/fre= ebsd-perl/20130609.freebsd-perl > >=20 > > I don't want to start yet another bikeshed here. Maybe link above will > > make some things more clear to you. >=20 > Thanks -- I wasn't aware of the freebsd-perl mailing list. >=20 > I just finished reading the entire thread. The justification seems to > be "because Fedora and Debian do it" (that's the best I can find). > Okay, fine/great/whatever -- I guess that's a form of justification, > just not one I was hoping for. I won't dwell on this at this point -- I > got the answer I was looking for. No the justification is that we use to have a perl-after-upgrade script to workaround the fact that we used major.minor.patchlevel my bypassing the pa= ckage tool to modify directly the content of the package database and more some f= iles on the file system each time a new perl update comes (like perl 5.12.2 -> 5.12.4) without this script being run every single minor update of perl was requiring manual intervention to fix up all the installed packages whereever they came from ports or package etc. The reference concerning Fedora/Debian was just when some asked if we were = doing something exotic to say no this is a "normal way" of doing things, look oth= ers do and the perl build system is extecting use to do that. >=20 > I see no actual harm in moving to major.minor, but the issue here is > that backwards compatibility in Mk/bsd.perl.mk for existing perl > installations. >=20 > Many people, for example, do not want to build X.org from source -- so > they pkg_add -r X, then build other bits/pieces related to X from > ports/source. Even more people do this for OpenOffice/LibreOffice or > whatever it's called today ( :-) ). >=20 > This "combination" needs to be supported. I know it hurts to have to > retain backwards compatibility, but it's necessary given how all of this > was designed. This has never been supported neither been unsupported, this commit doesn't changed anything here. >=20 > Such backwards compatibility could be removed, as I said, once > sufficient time has passed, particularly once the FreeBSD versions > shipping with a ports tree snapshot with perl versions older than those > in r320679 have been EOL'd. After that you could remove the framework > and cite EOL on such support. This is normal too -- for example on > occasion FreeBSD [67].x people show up on -ports and complain that > something won't build/some part of the Mk/* framework is broken for > them, and EOL is the proper response to that. Such compatibility hasn't been removed but improved with this patch: old behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1 then the perl path was changed and all compatibility was broken. new behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1: nothing to do >=20 > I know this probably won't hold any ground because I'm not one any > longer, but I was a FreeBSD ports committer myself some years ago (~5), > so please don't think that I'm just flying off the handle without some > existing familiarity with things. >=20 > If there is truly going to be a "split" between ports and packages > in this way, then someone needs to start doing SVN tagging/branches > for major changes like this. This has never been the matter of the patch and noone said that their will = be a split like this in the futur. regards, Bapt --qxfKREH7IwbezJ+T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHKjPMACgkQ8kTtMUmk6EwRSQCfVVxBB216SMXY+JZ4IBUdE7CW 38YAn2+y64X90lKtmpUZjlz8zVCyilss =w2Y1 -----END PGP SIGNATURE----- --qxfKREH7IwbezJ+T--