From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 07:15:55 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 48F7A85B; Wed, 26 Jun 2013 07:15:55 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id E35D5125F; Wed, 26 Jun 2013 07:15:54 +0000 (UTC) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id ACDCCA80CA; Wed, 26 Jun 2013 09:15:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3k+dCIupgo6m; Wed, 26 Jun 2013 09:15:42 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1C504A80BE; Wed, 26 Jun 2013 09:15:41 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id B04D773A1C; Wed, 26 Jun 2013 00:15:37 -0700 (PDT) Date: Wed, 26 Jun 2013 00:15:37 -0700 From: Jeremy Chadwick To: Baptiste Daroussin Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626071537.GA69414@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> <20130626061219.GA68398@icarus.home.lan> <20130626064051.GG93612@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626064051.GG93612@ithaqua.etoilebsd.net> 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 07:15:55 -0000 On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote: > 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. > > > > Understood, I just hope this can get addressed/fixed sooner than later, > > because what we have right now is reproducible breakage. :-) > > > > > > 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 > > > > > > 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. > > > > 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: > > > > http://www.freebsd.org/ports/index.html > > http://www.freebsd.org/doc/en/articles/linux-users/software.html > > > > 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 exactly 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. Thanks for the clarification and the education on this point -- like I said, I have no experience with pkg(8) and its kin. > > 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 package > 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. Please go look at Mk/bsd.port.mk and look up PKG_DBDIR. Just go look for it throughout the entire file and look at how/where it's used. It's used *heavily* throughout dependency checking and actual installation (think "Registering installation of ..." messages and what happens under the hood, if I remember right -- otherwise you have a port installed that you cannot pkg_delete). > > 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. > > > > 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. But only when looking forward, not when looking at existing installations or new installations. I will repeat my instructions for how to reproduce the problem: 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 Please go do it on a fresh FreeBSD 9.2-RELEASE system and watch what happens -- it breaks, and that breakage results in leftover shit in LOCALBASE. > > > > 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? > > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl > > > > > > I don't want to start yet another bikeshed here. Maybe link above will > > > make some things more clear to you. > > > > Thanks -- I wasn't aware of the freebsd-perl mailing list. > > > > 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 package > tool to modify directly the content of the package database and more some files > 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. That sounds like a mess, and I agree getting rid of that sounds great. I wasn't aware of that piece. But my stand on the breakage due to the backwards compatibility shims not being there stands. > 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 others > do and the perl build system is extecting use to do that. On the Solaris systems I use to administrate, I remember the paths containing major.minor.patchlevel. I doubt I'll find anything out about this in any of the perl documentation online though. > > 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. > > > > 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 ( :-) ). > > > > 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. See above, re: what the commit has broken. > > 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 See above, re: only looking forward, not looking at existing support and what happens if someone does what I said. > > 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. > > > > 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. Please correct me if I'm wrong here -- and god do I hope I am -- but the short version sounds to me like you're saying "nothing is wrong with the commit, nothing is broken, there is no problem, what are you complaining about?" I want to make sure I understand if that's what you're saying before I react past this point. But I would urge you to go do what I said, re: those 5 commands, and watch the breakage for yourself. Of course, I guess the alternate "solution" would be to have whoever maintains the official package sites (not for pkg, but pkg_*) update all the packages in Latest/ so that they refer to the new path convention... -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB |