Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Jul 2013 21:41:28 -0700
From:      Jeremy Chadwick <jdc@koitsu.org>
To:        Baptiste Daroussin <bapt@freebsd.org>
Cc:        culot@freebsd.org, freebsd-ports@freebsd.org, Andrej Zverev <az@freebsd.org>
Subject:   Re: Recent Mk/bsd.perl.mk changes (r320679)
Message-ID:  <20130706044128.GA21103@icarus.home.lan>
In-Reply-To: <20130626102306.GA71709@icarus.home.lan>
References:  <20130626001406.GA63314@icarus.home.lan> <CAD5bB%2BgMrttUuxcGGKUxCvP2No-y%2B8JzBRHLW51f%2BAUtMaTJoQ@mail.gmail.com> <20130626061219.GA68398@icarus.home.lan> <20130626064051.GG93612@ithaqua.etoilebsd.net> <20130626071537.GA69414@icarus.home.lan> <20130626102306.GA71709@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 26, 2013 at 03:23:06AM -0700, Jeremy Chadwick wrote:
> On Wed, Jun 26, 2013 at 12:15:37AM -0700, Jeremy Chadwick wrote:
> > 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...
> 
> And it just occurred to me: thanks to your tip about perl-after-upgrade,
> the below works.  It should be crystal clear the methodology.
> 
> I tested this on a bare 9.1-RELEASE system using devel/p5-Config-Record
> as a test subject (since it has no dependencies and builds fast), with
> both pkg_add -r perl (i.e. package with the old pathing scheme in
> place), and then alternately lang/perl5.14 from ports (at r320679).  No
> more errors, no more cruft, no more issues.
> 
> And like I said earlier: once all the FreeBSD releases get EOL'd and the
> packages which make use of the major.minor.patchlevel scheme are
> gone/nuked from orbit, this simple code can be removed.
> 
> -- 
> | Jeremy Chadwick                                   jdc@koitsu.org |
> | UNIX Systems Administrator                http://jdc.koitsu.org/ |
> | Making life hard for others since 1977.             PGP 4BD6C0CB |
> 
> Index: bsd.perl.mk
> ===================================================================
> --- bsd.perl.mk	(revision 321789)
> +++ bsd.perl.mk	(working copy)
> @@ -50,7 +50,14 @@ Perl_Pre_Include=			bsd.perl.mk
>  PERL_Include_MAINTAINER=	perl@FreeBSD.org
>  
>  PERL_VERSION?=	5.14.4
> +
> +# Legacy support for old perl packages which use the deprecated
> +# (as of r320679) major.minor.patchlevel pathing scheme.
> +.if exists(${LOCALBASE}/bin/perl-after-upgrade)
> +PERL_VER?=	${PERL_VERSION}
> +.else
>  PERL_VER?=	${PERL_VERSION:C/\.[0-9]+$//}
> +.endif
>  
>  .if !defined(PERL_LEVEL) && defined(PERL_VERSION)
>  perl_major=		${PERL_VERSION:C|^([1-9]+).*|\1|}

PR 180340 has been filed for this matter to ensure it does not disappear
off people's radar:

http://www.freebsd.org/cgi/query-pr.cgi?pr=180340

-- 
| Jeremy Chadwick                                   jdc@koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130706044128.GA21103>