Date: Mon, 20 Aug 2001 18:38:27 +0300 (EEST) From: Maxim Sobolev <sobomax@FreeBSD.ORG> To: knu@iDaemons.org (Akinori MUSHA) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), 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: <200108201539.f7KFd7N16456@vega.vega.com> In-Reply-To: <no.id> from "Akinori MUSHA" at Aug 20, 2001 11:53:17 PM
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. Then it makes even more questionable the usability of the new feature. If our dependency mechanist works, then you will be prevented from deleting shared library until there are still packages that require it, isn't it? Logically, one would be able to delete package only when there are no more packages that depend on it, so why to leave useless libfoo.so.X behind then? > 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. I think opposite. It sound to me like it would encourage users to delete all package contents expept of shared library and expect that the resulting setup will continue working, but in many cases it won't! > 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. No, we can and should (as long as the amount of possible cases is not infinite, which isn't the case obviously ;). > 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) No, you are trying to solve the problem from the wrong end. XEmacs should be fixed instead to detect installed libraries and expand its LIB_DEPENDS accordingly to ensure proper dependency registration. After all, how in this situation the user expected to know which packages he/she have to remove with `-P' and which without? > > 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. Where is the gurantee that the user will install new library after deleting the old version of package with `-P'? With this option it is very easy to shoot yourself in a foot by deleting some packages with `-P', forget about it and run into the problems later, when LIB_DEPENDS will detect shared library of partially removed package, thus breaking the build in strange ways. > 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? Yes, though I'm still don't see much point in this option. However, I would not object to its inclusion into pkg_install as long as the following criterias are meet: 1. It should be clear indicated in the manpage that the setup resulted from the usage of `-P' option is completely unsupported by us (i.e. The Project) and the user should use this option only when he/she really understands all implications (some of them I outlined above); 2. This option is not enabled by default; 3. Nobody else disagrees. Moreover, to protect users from some of the shortcomings above I would propose to move leftover shared libraries into some form of attic (e.g. lib/compat/), instead of leaving them in the lib/ so it is immediately clean what shared libraries are there only for compatibility purposes. Then, our dependency resolution mechanism could be teached to ignore those directories thus eliminating the possibility of misdetection of dependency. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108201539.f7KFd7N16456>