Re: aptitude is dangerous - any replacement?

2017-03-22 Thread Vincent Lefevre 
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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-22 Thread Nemeth Gyorgy 
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.

Re: aptitude is dangerous - any replacement?

2017-03-22 Thread Johann Spies 
What I do if I want to use experimental (or sid if I am on testing) is to
put
the deb-src-lines in my sources.list and then build a package when needed.
I find wajig convenient to use (another front end to apt) in this case e.g.

$ wajig build julia

Regards
Johann
-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 16:55:36 -0600, Joe Pfeiffer wrote:
> Vincent Lefevre  writes:
> > By default, the apt preferences are such that unstable is preferred
> > over experimental. But as explained in
> >
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795228
> >
> > this is not the case with aptitude's resolver:
> >
> > | With the SolutionCost of "removals", aptitude doesn't take into account
> > | installing by priorities or non-default releases, it just tries to
> > | minimise the removals, so seing that it could solve the problem by
> > | upgrading to 2.7-1~exp1, it just did that.
> 
> That appears (from my experience and reading for a few minutes, at any
> rate) to only come into play when there are conflicts to be resolved.

Not just conflicts, but also unfulfilled Depends and Recommends
(since 0.8-1 for Recommends, as a fix of #819636). This happens
even more when one has packages on hold.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Joe Pfeiffer 
Vincent Lefevre  writes:

> On 2017-03-21 21:39:40 +0100, Sven Joachim wrote:
>> On 2017-03-21 21:19 +0100, Vincent Lefevre wrote:
>> > aptitude ignores the apt preferences.
>> 
>> Huh?  At least on my systems, it obeys them.
>
> Perhaps with your configuration. And this is probably also true when
> the full resolver is not involved. But this is not the general case.
>
> By default, the apt preferences are such that unstable is preferred
> over experimental. But as explained in
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795228
>
> this is not the case with aptitude's resolver:
>
> | With the SolutionCost of "removals", aptitude doesn't take into account
> | installing by priorities or non-default releases, it just tries to
> | minimise the removals, so seing that it could solve the problem by
> | upgrading to 2.7-1~exp1, it just did that.

That appears (from my experience and reading for a few minutes, at any
rate) to only come into play when there are conflicts to be resolved.
In the normal case my experience is that the pinnings I've selected
appear to be honored.

All the same, thanks for alerting me to the SolutionCost setting.  I've
also got it set to "removals" which, after reading a bit, doesn't look
like a good idea.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
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).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 21:39:40 +0100, Sven Joachim wrote:
> On 2017-03-21 21:19 +0100, Vincent Lefevre wrote:
> > aptitude ignores the apt preferences.
> 
> Huh?  At least on my systems, it obeys them.

Perhaps with your configuration. And this is probably also true when
the full resolver is not involved. But this is not the general case.

By default, the apt preferences are such that unstable is preferred
over experimental. But as explained in

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795228

this is not the case with aptitude's resolver:

| With the SolutionCost of "removals", aptitude doesn't take into account
| installing by priorities or non-default releases, it just tries to
| minimise the removals, so seing that it could solve the problem by
| upgrading to 2.7-1~exp1, it just did that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Sven Joachim 
On 2017-03-21 21:19 +0100, Vincent Lefevre wrote:

> On 2017-03-21 08:36:40 -0600, Joe Pfeiffer wrote:
>> See the apt_preferences man page for information on prioritizing
>> distributions.  My own preferences file contains
>> 
>> Package: *
>> Pin: release a=testing
>> Pin-Priority: 700
>> 
>> Package: *
>> Pin: release a=stable
>> Pin-Priority: 650
>> 
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 600
>> 
>> Package: *
>> Pin: release a=experimental
>> Pin-Priority: 550
>
> aptitude ignores the apt preferences.

Huh?  At least on my systems, it obeys them.

Cheers,
   Sven

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 08:36:40 -0600, Joe Pfeiffer wrote:
> See the apt_preferences man page for information on prioritizing
> distributions.  My own preferences file contains
> 
> Package: *
> Pin: release a=testing
> Pin-Priority: 700
> 
> Package: *
> Pin: release a=stable
> Pin-Priority: 650
> 
> Package: *
> Pin: release a=unstable
> Pin-Priority: 600
> 
> Package: *
> Pin: release a=experimental
> Pin-Priority: 550

aptitude ignores the apt preferences.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Nemeth Gyorgy 
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. 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.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Joe Pfeiffer 
Vincent Lefevre  writes:

> I've just noticed that aptitude upgraded packages from unstable to
> experimental versions (just with 'U' from the UI) without any warning!!!
> Again.
>
> Is there any replacement? Or a way to make aptitude ignore
> experimental packages?
>
> Note: I still want to keep experimental in my sources.list for the
> cases where I *explicitly* request experimental packages.

See the apt_preferences man page for information on prioritizing
distributions.  My own preferences file contains

Package: *
Pin: release a=testing
Pin-Priority: 700

Package: *
Pin: release a=stable
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

Package: *
Pin: release a=experimental
Pin-Priority: 550

So I see packages from all of these distributions, but when
automatically selecting versions to install it prefers testing, second
choice stable, third unstable and last experimental.

[retraction] aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 12:31:29 +0100, Vincent Lefevre wrote:
> I've just noticed that aptitude upgraded packages from unstable to
> experimental versions (just with 'U' from the UI) without any warning!!!

After a closer look, I've found that aptitude was not the culprit
here.

The apt-show-versions utility claimed that these packages were in
experimental, but this was a wrong assumption: in fact, there was
no reliable way to determine the actual source (on another machine,
apt-show-versions claims that the same version comes from unstable).

That said, it is still possible that aptitude can install experimental
packages without any warning, and the developers don't want to fix
this bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795228

(That time, the log was explicit about the installation of the
experimental version.)

Due to this bug, I've been using

  Aptitude::ProblemResolver::SolutionCost "safety, removals";

for one year, and it seems that this solves the problem with
experimental packages (but the drawback is that this does not
prevent removals as the default solution).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Lisi Reisz 
On Tuesday 21 March 2017 11:31:29 Vincent Lefevre wrote:
> Is there any replacement? Or a way to make aptitude ignore
> experimental packages?
>
> Note: I still want to keep experimental in my sources.list for the
> cases where I *explicitly* request experimental packages.

Can experimental not be pinned, like backports?  I've ner tried to use it.

Lisi

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 09:03:47 -0500, David Wright wrote:
> On Tue 21 Mar 2017 at 14:10:09 (+0100), Vincent Lefevre wrote:
> > Now... After a closer look, I've found that aptitude was not the
> > culprit here.
> 
> Perhaps you could write this in a reply to the OP so that people
> don't have to wade through the thread to the middle of a posting
> to find this out. It could be even tagged [retraction].

OK, thanks for the idea. I've done this with details on the behaviors
of aptitude.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread David Wright 
On Tue 21 Mar 2017 at 14:10:09 (+0100), Vincent Lefevre wrote:
> Now... After a closer look, I've found that aptitude was not the
> culprit here.

Perhaps you could write this in a reply to the OP so that people
don't have to wade through the thread to the middle of a posting
to find this out. It could be even tagged [retraction].

Cheers,
David.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Dominik George 
>> apt also uses apt-listbugs...
>
>Yes, but one can't exclude a package listed by apt-listbugs.
>With aptitude, one just goes to the package and hits ":".

Sure. Just press h on the package.

-nik

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 14:27:38 +0100, Dominik George wrote:
> >1. When I want to exclude some buggy packages. I often do this with
> >   aptitude, where major bugs can be reported by apt-listbugs.
> 
> apt also uses apt-listbugs...

Yes, but one can't exclude a package listed by apt-listbugs.
With aptitude, one just goes to the package and hits ":".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Dominik George 
>1. When I want to exclude some buggy packages. I often do this with
>   aptitude, where major bugs can be reported by apt-listbugs.

apt also uses apt-listbugs...

-nik

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 13:02:02 +0100, Dominik George wrote:
> >I meant a replacement with a text UI.
> 
> I never had any situation where this would have helped me instead of
> being clumsy and painful within 12 years of systems administration.
> 
> What's your use case?

1. When I want to exclude some buggy packages. I often do this with
   aptitude, where major bugs can be reported by apt-listbugs.

2. When I want to upgrade some packages only (choosing packages from
   a list by a few keystrokes is the easiest way).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 08:00:52 -0400, Stefan Monnier wrote:
> > Note: I still want to keep experimental in my sources.list for the
> > cases where I *explicitly* request experimental packages.
> 
> I keep these extra thingies commented out in my sources.list and
> whenever I want to explicitly request some package from them,
> I uncomment the line, redo the `update` and then the install, after
> which I try not to forget to comment it out again,

But then, you cannot know when a package from experimental is
upgradeable. This was the whole point here, because I have a
cron script that does:

  apt-show-versions -u | grep manually

so that I know when I may need to upgrade a package that was installed
from experimental.

Now... After a closer look, I've found that aptitude was not the
culprit here. Even though I got:

libreoffice-common:all/experimental *manually* upgradeable from 1:5.2.6-1 to 
1:5.3.1-1
libreoffice-java-common:all/experimental *manually* upgradeable from 1:5.2.6-1 
to 1:5.3.1-1
[...]

version 1:5.2.6-1 was never in experimental. It just comes from
unstable, so that aptitude was OK. The bug is in apt-show-versions,
which I've just reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858337

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Darac Marjal 

On Tue, Mar 21, 2017 at 12:31:29PM +0100, Vincent Lefevre wrote:

I've just noticed that aptitude upgraded packages from unstable to
experimental versions (just with 'U' from the UI) without any warning!!!
Again.

Is there any replacement? Or a way to make aptitude ignore
experimental packages?

Note: I still want to keep experimental in my sources.list for the
cases where I *explicitly* request experimental packages.


You could try creating a file in /etc/apt/apt.conf.d with the following 
content:


APT::Default-Release "unstable";

man 5 apt.conf" says the following:

 Default-Release
		   Default release to install packages from if more than one 
		   version is available. Contains release name, codename or 
		   release version. Examples: 'stable', 'testing', 'unstable', 
		   'stretch', 'buster', '4.0', '5.0*'. See also 
		   apt_preferences(5).  



--
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



--
For more information, please reread.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Davor Balder 



On 21/03/17 23:00, Stefan Monnier wrote:

Note: I still want to keep experimental in my sources.list for the
cases where I *explicitly* request experimental packages.

I keep these extra thingies commented out in my sources.list and
whenever I want to explicitly request some package from them,
I uncomment the line, redo the `update` and then the install, after
which I try not to forget to comment it out again,


 Stefan


I second that - that is what I've been doing as well.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Dominik George 
>I meant a replacement with a text UI.

I never had any situation where this would have helped me instead of being 
clumsy and painful within 12 years of systems administration.

What's your use case?

-nik

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Stefan Monnier 
> Note: I still want to keep experimental in my sources.list for the
> cases where I *explicitly* request experimental packages.

I keep these extra thingies commented out in my sources.list and
whenever I want to explicitly request some package from them,
I uncomment the line, redo the `update` and then the install, after
which I try not to forget to comment it out again,


Stefan

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Intense Red 
> I meant a replacement with a text UI.

   dselect is still in the repository, though it's deprecated.


-- 
"It is said that no one truly knows a nation until one has been inside its 
jails. A nation should not be judged by how it treats its highest citizens, 
but its lowest ones." -- Nelson Mandela.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Davor Balder 

To upgrade I always do apt-get update && apt-get upgrade.

When jumping releases I also use apt-get dist-upgrade

This seems to be the safest option thus far (my systems have been 
running smoothly).



On 21/03/17 22:37, Vincent Lefevre wrote:

On 2017-03-21 12:34:23 +0100, Dominik George wrote:

Is there any replacement?

Yes, apt.

I meant a replacement with a text UI.

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
On 2017-03-21 12:34:23 +0100, Dominik George wrote:
> >Is there any replacement?
> 
> Yes, apt.

I meant a replacement with a text UI.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: aptitude is dangerous - any replacement?

2017-03-21 Thread Dominik George 
>Is there any replacement?

Yes, apt.

-nik

aptitude is dangerous - any replacement?

2017-03-21 Thread Vincent Lefevre 
I've just noticed that aptitude upgraded packages from unstable to
experimental versions (just with 'U' from the UI) without any warning!!!
Again.

Is there any replacement? Or a way to make aptitude ignore
experimental packages?

Note: I still want to keep experimental in my sources.list for the
cases where I *explicitly* request experimental packages.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)