Date: Mon, 20 Aug 2001 23:53:17 +0900 From: "Akinori MUSHA" <knu@iDaemons.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: audit@FreeBSD.org, green@FreeBSD.org (Brian F. Feldman), mike@FreeBSD.org (Mike Barcroft), ports@FreeBSD.org Subject: Re: adding -P option to pkg_delete(1) Message-ID: <86y9oe4wbm.wl@archon.local.idaemons.org> In-Reply-To: <200108201246.f7KCkNg15792@vega.vega.com> References: <no.id> <200108201246.f7KCkNg15792@vega.vega.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At Mon, 20 Aug 2001 15:46:23 +0300 (EEST),
sobomax wrote:
> Ok, let me put it differently - I just do not see any reasonable use for
> the new option. What the user would gain by removing all package content
We would certainly not (have to) gurantee anything. As mentioned in
the man page, -P is supposed to be used given a user knows what s/he
is doing.
> except of shared libraries? We couldn't reasonably gurantee that package
> will work after such partial removal, so I suppose that we are just asking
> ourselves a trouble in the form on increased number of PRs "hey, I
> pkg_delete'd -P libfoo-1.0, and bar-2.0 stopped working." Also such
> partial removal will screw our dependency system - LIB_DEPENDS will
That doesn't make sense! As long as our dependency system works as
you say in the latter part, one could not pkg_delete libfoo when
bar-2.0 properly LIB_DEPENDS on it as you say in the former part.
Besides, the fact is opposite. The -P option prevents us from getting
the "hey, I pkg_delete'd -P libfoo-1.0, and bar-2.0 stopped working."
type of PRs.
Some pieces of software in ports detect and pick up libraries which
are not listed in LIB_DEPENDS. For instance, the XEmacs port picks up
and links libldap automatically without a user's notice. So in this
case, we may get a PR which says "hey, I pkg_delete'd
openldap-2.0.11_4, and xemacs-21.1.14 stopped working somehow.". Note
that I am not denying that we should add `--without-openldap' or
something to the port's CONFIGURE_ARGS, but we cannot cover every
case.
Granted, s/he would never get into trouble if there were the -P option
and he knew of that. It doesn't solve anything essentially, but at
least it helps people in a certain case to two. (See below)
> detect shared library, but at the same time all headers of the package
> will be missed.
That's no problem. Because when one (re)builds a new binary, s/he
will use the new version of the headers and the library anyway. It's
just for backward (binary) compatibility.
By the way, do you remove all the old shared libraries everytime you
do a `make world'? I suppose not, since you know you (or other users)
might still have some executables and shared libraries that depend on
the older ones.
Don't you install compat4x after you upgrade one of your 4-STABLE box
to 5-CURRENT? I suppose yes, for the same reason.
Given the above, you may reasonably want to preserve shared libraries
when you upgrade a package.
Do I make myself clear?
--
/
/__ __ Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"Freeze this moment a little bit longer, make each impression
a little bit stronger.. Experience slips away -- Time stand still"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86y9oe4wbm.wl>