Date: Tue, 21 Aug 2001 01:28:33 +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: <86wv3y4rwu.wl@archon.local.idaemons.org> In-Reply-To: <200108201539.f7KFd7N16456@vega.vega.com> References: <no.id> <200108201539.f7KFd7N16456@vega.vega.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At Mon, 20 Aug 2001 18:38:27 +0300 (EEST),
sobomax wrote:
> > 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?
The world is not 100% made of packages, and a package system cannot
handle everything.
Sometimes a user can be lazy to (tell his/her users to) rebuild and
reinstall all the binaries that depend on a library that's being
updated via ports/packages, when s/he is sure that keeping the old
version would save everything that's working at the time. It may
include packages, or it may include some users' locally built stuff.
Ideally, I admit packages should be strictly administrated within the
framework. but users' stuff could not.
> > 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!
Define many, please? Most shared libraries work by itself without
depending on version specific configuration files. That's one of the
purpose we have shared library versions and allow several versions of
a library to coexist.
I think I can name concrete examples as much as you want.
> No, we can and should (as long as the amount of possible cases is not
> infinite, which isn't the case obviously ;).
That's not a good attitude to live with the reality. If everything
worked as you think it "should", you'd have no problem in the first
place. At least until we fix most of them, we certainly need this
kind of workarounds.
> 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?
Putting -P is safer in general. That's all. I'm not going to
overrate it.
> 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.
You have a point here. So, I liked your "lib/compat" idea in the last
paragraph.
> > 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:
I'm glad we are walking up to each other.
> 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);
I agree with that, but then we should also mention that there are many
other "unsupported" commands and options like pkg_update, pkg_add -I,
pkg_delete -D, etc. . In my opinion, ports/packages are already
flawful and is hard to guarantee much. For example, pkg_add installs
a package even though a different version is still installed.
Anyway, it is a good thing to document as much as we can.
> 2. This option is not enabled by default;
Sure. Because it is an "option" as it is. :)
> 3. Nobody else disagrees.
So far it seems.
> 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.
That's a pretty good idea. I'll test the mechanism with my
pkg_deinstall(1) utility and see if/how it works, then I'll feed it
back to pkg_delete.
Actually -P was first implemented in pkg_deinstall(1) and I am feeding
it back.
Regards,
--
/
/__ __ 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?86wv3y4rwu.wl>