Date: Wed, 26 Jun 2013 08:40:52 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: Jeremy Chadwick <jdc@koitsu.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: <20130626064051.GG93612@ithaqua.etoilebsd.net> In-Reply-To: <20130626061219.GA68398@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> <CAD5bB%2BgMrttUuxcGGKUxCvP2No-y%2B8JzBRHLW51f%2BAUtMaTJoQ@mail.gmail.com> <20130626061219.GA68398@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130626064051.GG93612>