Greetings,
I currently manage several RELENG_8 servers. Recent changes in the
manner in which base && ports must be managed have resulted in more
than a fair amount of grief. the migration from cv(sup) --> subversion
required re-working long standing, carefully crafted management
procedures to be pitched to the trash, and re-invented. A recent change
to the Perl installation structure presents an entire new set of headaches,
rendering up(grading|dating) near, if not completely impossible. Case in
point; an i386 8.3-STABLE box with it's last update just prior to the
Perl structure change, began a new update this morning via portmaster(8).
As it reached 163/300 upgrade targets, the process died with a missing
dependency error -- p5-XML-Simple. Exploring /var/db/pkg revealed that
it had already been installed/upgraded (p5-XML-Simple-2.20). Any
attempt to re-install/forceably upgrade the module failed with
"p5-XML-Simple-2.20 not installed". According to /usr/ports/UPDATING;
20130612:
AFFECTS: users of lang/perl* and any port that depends on it
AUTHOR: az at FreeBSD.org
lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3
The directory structure where Perl is installed has also been modified:
"major.minor" is now used instead of
"major.minor.patchlevel".
The "perl-after-upgrade" script has been removed.
Please rebuild all Perl ports and all ports that depend on it:
# portmaster -r perl
or
# portupgrade -rf perl
or
# pkg install -fR perl
# portmaster -r perl
===>>> perl is not installed
===>>> Aborting update
Hmm...
# ls /usr/local/lib/perl5
5.14 5.14.2 site_perl
Yep. Perl is installed.
Any attempt to upgrade/update *any* Perl, or Perl related
ports fail. I think it's probably fair to say, that the
restructuring of the Perl installation is the cause -- no?
How does reading, and following the instruction(s) provided
in /usr/ports/UPDATING help, or resolve such matters?
WHY was this change *required*? How does this help FreeBSD's
base users? Couldn't th(is|ese) changes been given enough
forethought to have provided tools/procedures that guarantee/
ensure that those affected, can make the transition smoothly?
That those who's income is directly affected by FreeBSD, be
relatively unencumbered by the changes?
While I recognize that many might argue that updating more
frequently would eliminate most -- if not all of these issues.
I can only say, that that _shouldn't_ be the case. For many,
schedules don't always permit this, and if given the right
tools, this wouldn't be an issue at all.
While I also recognize that those whom haven't experienced
these issues, all of this might just sound like a "rant". I
don't believe that all of the problems generated by the
changes needed to have occurred.
So, in the end; why did Perl have to be relocated? Is my only
recourse at this point to
# cd /
# rm -rf .
slib the DVD into the slot, and push the reset button?
Thank you for all your time, and consideration in this matter.
--chris
I can't comment on the perl changes directly, but I can assure you that if you use port-mgmt/pkg (pkgng) and build your ports into packages via ports-mgmt/poudriere you will have zero upgrade problems -- a simple "pkg upgrade" will handle the scenario properly. I really haven't tried following UPDATING with portmaster/portupgrade to see what happens. I'd suspect that portmaster is doing something wrong, but further investigation is really necessary to have a solid conclusion of what happened on your server(s). For the first time in ages the ports environment on FreeBSD is rapidly evolving. There are many, many new features that benefit the whole of the userbase and will ease support and deployment across the board. We're trying to limit turbulence, but sometimes things are unforeseeable. This is the nature of the incredible flexibility of FreeBSD's ports; there's more than one way to do something.
Le Thu, 1 Aug 2013 08:31:45 -0700 (PDT), "Chris H" <bsd-lists at 1command.com> a ?crit :> Greetings, > I currently manage several RELENG_8 servers. Recent changes in the > manner in which base && ports must be managed have resulted in more > than a fair amount of grief. the migration from cv(sup) --> subversion > required re-working long standing, carefully crafted management > procedures to be pitched to the trash, and re-invented. A recent > change to the Perl installation structure presents an entire new set > of headaches, rendering up(grading|dating) near, if not completely > impossible.that's not new. A perl upgrade was always painful. I suggest to use poudriere to build yours packages and pkgng to manage them. As poudriere produces a consistent set of packages, an upgrade is painless (pkg upgrade -f) and you can deploy them on several machines. In fact poudriere and pkg saved me :) Regards.
On 08/01/2013 10:31 AM, Chris H wrote:> So, in the end; why did Perl have to be relocated? Is my only > recourse at this point to > # cd / > # rm -rf .When I get into this kind of bad situation, I usually do something slightly less drastic: # pkg_delete -a # find -d /usr/local -type d -exec rmdir {} \; This last command removes empty directories in /usr/local (it also produces lots of error messages when it tries to remove non-empty directories). Then I look through the contents of /usr/local, especially if there is anything in /usr/local/etc or /usr/local/libexec where some of my manually changed configuration files reside. And then I delete any crud left over that I know I don't need. After that, I rebuild all the ports from scratch. Finally, I do understand why you feel the need to vent, and I don't want to belittle your feelings of frustration. But I do think everyone is trying their best. I like to tell people that running FreeBSD or Linux is like owning a souped up sports car - usually it runs really well, but it often needs a lot of attention. (Windows is like driving a cheap car that breaks down all the time, but engine is designed in such a way as to be totally inaccessible with regards to repairs. And Apple is like driving a BMW - it mostly works well but you pay a lot for it.)