Date: Tue, 25 Jun 2013 23:12:19 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Andrej Zverev <az@freebsd.org> Cc: culot@freebsd.org, bapt@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626061219.GA68398@icarus.home.lan> In-Reply-To: <CAD5bB%2BgMrttUuxcGGKUxCvP2No-y%2B8JzBRHLW51f%2BAUtMaTJoQ@mail.gmail.com> References: <20130626001406.GA63314@icarus.home.lan> <CAD5bB%2BgMrttUuxcGGKUxCvP2No-y%2B8JzBRHLW51f%2BAUtMaTJoQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
For both pkg_* tools and ports, both use the same default base path
(/usr/local), **and** both register their bits in /var/db/pkg.
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.
> > 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.
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.
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.
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.
--
| 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?20130626061219.GA68398>