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

Re: aptitude is dangerous - any replacement?



On 2017-03-22 07:50:09 +0100, Nemeth Gyorgy wrote:
> 2017-03-21 23:02 keltezéssel, Vincent Lefevre írta:
> > On 2017-03-21 16:21:25 +0100, Nemeth Gyorgy wrote:
> >> 2017-03-21 14:38 keltezéssel, Vincent Lefevre írta:
> >>> Yes, but one can't exclude a package listed by apt-listbugs. 
> >> You can. Just press 'h' (hold), and don't continue apt-get.
> > I didn't know that apt-listbugs could do that. This is not documented
> > and I've never tried.
> >
> >> On the next apt-get start this package will be in 'hold' state. And
> >> later apt-listbugs will unhold the package automatically when the
> >> bug is closed.
> > One problem is that maintainers sometimes forget to close bugs
> > (in particular if the bug has been fixed by upstream). It would
> > be better to ask again when a new version is available (a bit
> > like aptitude's "freeze" feature).
> >
> I currently use sid on my desktop (so bugs are relatively frequent) and
> usually don't have to unhold packages manually. I didn't analyze
> /usr/lib/ruby/vendor_ruby/aptlistbugs/aptcleanup deeply (this is in the
> cron.daily file), but I think it also checks the version. Code snippet:
> 
> # are bugs that the user fears still affecting unpinned_candidate_version ?
>     $stderr.puts "Checking bug(s) #{feared_list} for
> #{pkg_key_with_vers}" if $DEBUG
>     optionB = nil
>     if feared_list != "" and feared_list != nil
>       optionB = "-B #{feared_list}"
>     end
> 
> So it seems that version check is also in the script.

Yes, to know whether the candidate version has been fixed or not
by comparing the version with the "fixed" field in the BTS. But
if the bug is not marked as fixed in the BTS, this won't work.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: