Recent bsd.port.mk changes
Kris Kennaway
kris at obsecurity.org
Mon Apr 21 14:03:00 PDT 2003
On Sun, Apr 20, 2003 at 06:55:32PM +0400, Sergey Matveychuk wrote:
> Joe Marcus Clarke wrote:
> > On Fri, 2003-04-18 at 00:57, Kris Kennaway wrote:
> > > In your case since the PREFIX is different they don't actually
> > > conflict so one might argue that it should be allowed. I suppose
> > > that's something that could be checked in bsd.port.mk by extracting
> > > the prefix for the existing package from the contents file and
> > > comparing to PREFIX.
>
> Disagree. This case really dangerous for users. What happened if you try
> install a port with other PREFIX than already installed port with the same
> version? You'll lose port information in PKG_DBDIR. And when you'll
> deinstall new installed port you'll have got orphan files.
> That is user must understand the dangerous and use FORCE_PKG_REGISTER=yes
> for his responsibility.
Yes, that's a good point (I raised it in my original email). Perhaps
the real solution for Joe is to set PKG_DBDIR when he is doing test
installs in another prefix, so the registration cannot possibly
conflict with real packages.
However, there are other cases that are broken (pointed out by knu):
If you compile e.g. python modules against multiple versions of
python, they will have different package names and install in
different places (so the packages do not conflict at all), but the
same origin. The new check will not allow the user to do this.
Another case that is broken is when a port is built with different
options from the same directory. For example, ruby_r-qt2 and ruby-qt2
have a common origin but are different and should be allowed to
coexist. This kills the build of ruby_r-qt2gl:
http://bento.freebsd.org/errorlogs/i386-4-latest/ruby_r-qt2gl-0.14_1.log
We should think about how to fix this so it is allowed. Perhaps the
key is to compare the pkg-plist for the ports with the same origin to
see if any files conflict.
There also appears to be a bug that is performing substring matches on
existing packages, somehow.
http://bento.freebsd.org/errorlogs/i386-4-latest/kde-i18n-3.1.1.log
kde-i18n-3.1.1 is not installed, but a lot of *-kde-i18n-3.1.1 ports
are, and the build fails with
===> kde-i18n-3.1.1 is already installed - perhaps an older version?
> > This would be acceptable. However, the make deinstall would still
> > remove both versions. What about keeping make deinstall the same as it
> > was with one exception: if you type make deinstall in a port directory,
> > and the version specified by that port's Makefile is not installed (but
> > another version with the same origin is), then the other version would
> > be deinstalled. However, if a package is found that matches the version
> > specified in the port's Makefile, then only that version is removed. We
>
> Sounds good.
>
> > could then add a make deinstall-all target to handle deinstalling all
> > packages with the same origin. Something like what's attached.
>
> Kris, what do you think about this new target? I don't see necessity of it.
> I'd like to test this patch properly.
I'm no longer sure it will have the desired effect, given the points
raised above.
Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20030421/9f74fab3/attachment.bin
More information about the freebsd-ports
mailing list