Update of quazip-0.5.1 to quazip-0.6.2 fails
Dr. Peter Voigt
pvoigt at uos.de
Wed Mar 19 19:15:17 UTC 2014
Am Wed, 19 Mar 2014 18:09:43 +0100
schrieb Kurt Jaeger <lists at opsec.eu>:
> > > > I am running 10.0-RELEASE and when trying to upgrade
> > > > quazip-0.5.1 to quazip-0.6.2 after latest update of the ports
> > > > tree I obtain the following error:
> > > Please deinstall the old quazip before building the new port.
> > thanks for your feedback. However, I am not sure, if I've got you
> > right: Currently BUILDING of the new quazip version fails. How can
> > deinstallation of the old version correct this behavior?
> The build imports some definitions from old .h files or so ?
OK that helps.
> I saw the same problem, deinstalled the old version, build and
> it worked. There are cases where ports have this kind of quirk.
> Sometimes, it's documented in /usr/ports/UPDATING.
> > And if I force uninstallion of the old version and if subsequently
> > building of the new version should fail, I will be left with broken
> > dependencies:
> You are right, that might be a problem. You can handle it this way:
> Create a package file:
> pkg create quazip-0.5.1
> It will create a quazip-0.5.1.txz in the working directory.
> Then deinstall, and if the build fails, re-add the old pkg:
> pkg add quazip-0.5.1.txz
Yeah, thanks. I have learned a lot about pkg(ng) and packages. I
did create the backup package but did not need it, because installation
of new quazip version went smoothly.
> > Thanks for doing so. I am rather new to FreeBSD and do not yet know,
> > when there is time to directly contact a port maintainer. Until now
> > I have first reported an issue to the forum or the mailing list.
> > And in a second step I have informed the corresponding port
> > maintainer. Is this the recommended way to proceed?
> In general, informing the maintainer, probably generating a
> problem-report (using the command send-pr) is the correct way.
Ah, I have not been aware of the existence of this command. I'v used in
the past a more unformal way of sending an email containing the - in my
opinion - relevant information.
> In that special case
> shows that the update was done after the maintainer failed to approve
> the update. So in this particular case informing him might be
Well, I am obviously not much trained in reading the commit history. I
would conclude from the last entry "17 Mar 2014 15:54:23" and "Approved
by: maintainer timeout (nivit, >4 weeks)" that the maintainer did not
approve the commit and thus the commit remained untested. Can one
conclude from this that the maintainer is aware of problems without
reporting them? I cannot read that the maintainer "failed to approve".
Or can I assume for sure every port maintainer has subscribed to this
this mailing list? Please give me a hint, if I have got the wrong
More information about the freebsd-ports