[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#474947: the state of Bug#474947



Dropped debian-release from CC.

Elliott Mitchell wrote:
>>  - this patch reduces apt speed (not serious though, as I see) on most
>> operations with the cache;
> 
> I guess I should ask, do you have an less issues less relevant waiting in
> the wings? While more speed is good, that is worthless if it is badly
> broken.
Yes.

>>  - fix requires a big patch (small part of it was written by me, see #474947
>> thread);
>>  - this patch have to change internals of apt;
>>  - this patch can break apt API and ABI (don't checked);
> 
>>  - this patch definitely requires thorough review and testing;
> 
> Here it is a matter of the weightings. The flipside is without this
> fixed:
> 
>  - Almost certainly a significant number of users will run into this
> issue during the lifetime of Lenny (the history is 5-10 bugs/year; plus
> an unknown and likely large number of people who do not report it since
> they see it has already been reported and therefore presume work has
> already begun on fixing it).
Release notes have already an item about upgrading APT first and setting Cache-Limit, if I
recall correctly.

>  - This complicates debugging, as it escalates otherwise harmless issues
> to major severity (see #400768; while certainly an otherwise unrelated
> bug, if the MMap issue wasn't present, this bug would never have caused
> any problems).
It seems that 400768 was caused by other limits. Though I may be wrong.

>  - It is quite likely that upon upgrading to a version of Debian after
> Lenny, APT will again break due to this issue and again have to include
> a major warning in the release notes.
Yes :(

>  - As far as actual impact of the change we still do not know. Despite
> knowing about the first problem for at least 5 years (#178623 is the
> oldest report I have found), and knowing that it was still very
> definitely an issue for a minimum of nearly 2 years (#400768); we still
> do not have anything but rough guestimates. It might be that this is the
> time your estimate is wildly wrong, but we do not know since no patch has
> ever been tried. Why not try this in experimental? Then we would have
> real experience to judge how much work it will take to fix.
Please, leave this after Lenny. Testing in experimental is definitely not enough.

Yes, it's bad that this bug wasn't touched during long time.

>> I don't think this would be acceptable by release team.
> 
> Too a point I think I can summarize your position as: It is too dangerous
> to fix this in Lenny.
Yes.
> 
> Correspondingly I can summarize my position as: It is too dangerous NOT
> to fix in Lenny.
> 
> There is no clearly right answer here. The issue is which will damage
> Debian more; delaying the release, or releasing with another serious
> issue?
Well, old bug with clear instructions how to fix it is better that undiscovered bunch of
new ones which, If will not be discovered before Lenny, will affect user during all Lenny
lifetime. You also know that, firstly, Debian had full freeze in July 2008, freeze of core
components was at several months before.

>> Elliott, reason for this bug is apt architecture. Do you think we can easily
>> change architecture of the core package at freeze stage?
> 
> I have made no such claims. I am merely stating that this is a serious
> bug. Severe enough to seriously consider delaying the release. This is
> what the release team gets to decide, which is worse (neither option is
> good)?
Yes. So, If you claim this have to be fixed before Lenny, go ahead and ask Debian release
team what they think about changes in internals of apt and additional month(s) of testing.

> Yet, since you've got an initial patch, why not put that out in
> experimental?
I've have not written initial patch. I've written small part of the patch.

It might be found that fixing it isn't anywhere near as bad
> as you thought. Even though it changes the API/ABI, if no one has ever
> touched that field, the impact on other packages will be zero.
Yes, it will change ABI and API. This will cause recompiling packages that rely on apt
against new apt, and would cause breakage of some apt-dependent tools (such as aptitude,
perl and python bindings). Another big pain for other developers.

> Perhaps
> the release team will decide it is worth delaying the release, in which
> case a head start in testing will be of great value. Perhaps some other
> issue will force a delay of the release, in which case the extra time
> might allow sufficient testing.
Perhaps. And perhaps not.

My conclusion: please not force fixing this bug before Lenny until release team agree to
change internals of apt at this stage.

-- 
Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer.

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: