Date: Wed, 15 Nov 2006 14:10:52 -0500 From: Mikhail Teterin <mi@aldan.algebra.com> To: Erwin Lansing <erwin@freebsd.org> Cc: freebsd-bugs@freebsd.org, Parv <parv@pair.com> Subject: Re: bin/34628: [pkg_install] [patch] pkg-routines ignore the recorded md5 checksums Message-ID: <200611151410.52964.mi@aldan.algebra.com> In-Reply-To: <20061115182320.GF69151@droso.net> References: <200611142154.kAELsKN4007777@freefall.freebsd.org> <200611141703.38311.mi%2Bmx@aldan.algebra.com> <20061115182320.GF69151@droso.net>
next in thread | previous in thread | raw e-mail | index | archive | help
середа 15 листопад 2006 13:23 Ви написали: > > That's a surprisingly naive way of thinking... The CONFLICTS > > functionality is broken on occasion in bsd.port.mk, and not every port > > sets it anyway... > If CONFLICTS is broken, CONFLICTS should be fixed, not pkg_info. If some > ports don't set it, they should be fixed, not pkg_info. People should never get sick -- we don't need doctors. Programs should be bug-free, we don't need debuggers... But 'pkg_info -W' ALREADY detects the situation, which is never supposed to happen -- when multiple packages claim the file. According to both you and sobomax, this functionality should be ripped out. I disagree, and my change uses the checksums to help the user identify, which of the multiple packages is the right one. > > `pkg_info -W' would also be able to warn about checksum mismatches, which > > would suggest, a file has been modified (or corrupted) since getting > > installed. > > Now, that sounds more like a good idea, although in that case, the code > should moved outside the code for checking if multiple ports claim the > same file. The change was introduced to allow to determine, which of the multiple ports installed the current version of the file in question. It is trivial to modify it to compare the checksum in all cases, at the cost of slightly higher overhead (MD5File called always, even if only one port "claims" the file). > > Anyway, what is the overhead exactly? > > Explained elsewhere in this thread. And promptly refuted in a follow-up... Have you missed it? > Note, that my reaction was the same as sobomax' back in 2002 Erwin, that so wrong... Sobomax has expressed doubt and asked a bogus question. You should also note, that FIVE MONTHS passed between my submitting the PR (and assigning it to Maxim -- March 2002) and his expressing "the doubt" (August 2002). Considering, that he saw the patch and the discussion of it in February (2002) -- and requested I do the PR (a quote from his request is in the trace), his entire participation in the matter should be discounted... At the time JKH was still with us, and since he has expressed interest in the functionality, I simply transfered the PR to him. > and you then refused to give more information. ???? Please, quote a request for "more information", that you accuse me of "refusing" to honor? > As you haven't shown any interest in this PR since, I gathered you were no > longer interested and I closed it. Erwin, this is completely bizarre. So, not only does one have to describe a problem and offer a solution, one also needs to continuously "show interest", or else the problem will be deemed non-existant? > If you are willing to work on this, it would be great though. What ELSE can I do? I described the problem. I proposed a (fairly elegant, IMHO) solution. I've been using that solution myself for the last 4 years. You think, I need to do something else? Could one of you, please, just try the freaking patch for themselves, instead of trying to guess, what it does and does not do? Like Maxim in 2002, Parv just exhibited serious misunderstanding of the proposed change... It must be my failure to describe it, of course (who else can be to blame?), but I am at a loss, at how to do it better... It addresses a non-trivial use-case and requires a little bit more of attention span, than has so far been granted to it by various people quick to render their dismissing judgements... -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611151410.52964.mi>