Control: tags -1 + confirmed
Control: retitle -1 'aptitude upgrade paw+' should install paw if not installed
Hello Dan,
2004-08-31 02:35 Dan Jacobson:
Package: aptitude
Version: 0.2.15.2-1
Severity: minor
Extra arguments here
# aptitude upgrade ggggggggg #non package, and
# aptitude upgrade paw #real package
produce nary a wimper and all goes on as if the
user had never made a mistake.
This is not so nowadays, in my opinion it it now behaves correctly:
------------------------------
# aptitude upgrade ggggggggg
Couldn't find any package whose name or description matched "ggggggggg"
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 119 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude upgrade paw
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 119 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
------------------------------
Arguably, 'upgrade' could also install the existing package 'paw', but I think
that upgrade being "safe-upgrade" it is reasonable that by default in upgrade
mode aptitude refuses to install new packages. It could perhaps emit some
comment explicitly about what happens with 'paw', like "refusing to upgrade not
installed package", which was requested in the command line, but I think that
the current behaviour is fine, or at least "within reason".
By the way, when the user sees
Appending ``-'', ``+'', ``_'', or ``='' to the name of a package
will cause the package to be removed, installed, purged, or held
he wishes you would add reassuring statements regarding packages that
are already so appended, e.g. impose+, hamlib2++.
The documentation nowadays is different, but I think that it is worthwile to
note that this seemed to apply to commands "install", "remove", "purge" and
maybe others like "hold" or "reinstall".
Perhaps "upgrade" (now "safe-upgrade") was not meant to install new packages at
that time, but now the documentation says that the command accepts to have the
special per-package instructions:
safe-upgrade
[...]
If no <package>s are listed on the command line, aptitude will attempt to
upgrade every package that can be upgraded. Otherwise, aptitude will attempt
to upgrade only the packages which it is instructed to upgrade. The <package>s
can be extended with suffixes in the same manner as arguments to aptitude
install, so you can also give additional instructions to aptitude here; for
instance, aptitude safe-upgrade bash dash- will attempt to upgrade the bash
package and remove the dash package.
Personally I don't think that this is a good idea for the same reason that
created this bug report: + and - are valid characters of package names, so
overloading them causes confusion, unneded trickery/complexity when handling
options and other problems.
Investigating paw, paw++:
aptitude upgrade paw+
aptitude upgrade paw++
aptitude upgrade paw+++
all do nothing: additional arguments ignored valid, or not, with upgrade.
Worth to note that both "paw" and "paw++" are valid package names, it got
confused me initially.
So, according to the documentation, I believe that 'upgrade paw+' and 'upgrade
paw+++' should install the packages 'paw' and 'paw++' respectively, either the
documentation or the implementation should be changed.
# aptitude dist-upgrade paw+++|grep paw #OK
libpaw1 libtiff4 paw-common ssl-cert
libpacklib1 libpaw1 librrd0 libtiff4 paw++ paw-common ssl-cert
# aptitude dist-upgrade paw++|grep paw #no need for + at all:
libpaw1 libtiff4 paw-common ssl-cert
libpacklib1 libpaw1 librrd0 libtiff4 paw++ paw-common ssl-cert
# aptitude dist-upgrade paw+|grep paw #OK
libpaw1 libtiff4 paw-common ssl-cert
libpaw1 librrd0 libtiff4 paw paw-common ssl-cert
# aptitude dist-upgrade paw|grep paw #so indeed, no appending + needed with
dist-upgrade !
libpaw1 libtiff4 paw-common ssl-cert
libpaw1 librrd0 libtiff4 paw paw-common ssl-cert
In my system with 0.6.11-1+b1 the behaviour is now different:
------------------------------
a) These install 'paw' and 'paw++':
aptitude dist-upgrade paw+
aptitude dist-upgrade paw+++
b) These do nothing:
aptitude dist-upgrade paw
aptitude dist-upgrade paw++
------------------------------
I am not 100% sure which one is the correct behaviour, if the original or the
current one.
I am leaning towards this: that any kind of 'upgrade' should preferably not
install new packages unless explicitly stated, like it behaves now.
'dist-upgrade' is and can be allowed to be more adventurous than
'[safe-]upgrade', but still not go too far away unless explicitly requested to
install new packages.
But the documentation and different behaviours don't seem to match or work
predictably (also see below the case of 'impose+'), so something must be done in
any case.
I didn't try impose+.
In my system with 0.6.11-1+b1:
------------------------------
a) These want install impose+:
# aptitude -s upgrade impose++
(note 'upgrade')
#aptitude -s dist-upgrade impose++
The following NEW packages will be installed:
impose+ psutils{a}
0 packages upgraded, 2 newly installed, 0 to remove and 119 not upgraded.
Need to get 140 kB of archives. After unpacking 382 kB will be used.
Do you want to continue? [Y/n/?] n
b) These do nothing:
# aptitude -s upgrade impose+
# aptitude -s dist-upgrade impose+
------------------------------
The behaviour is different compared to the above case with 'paw*', because in
that case 'upgrade' didn't do anything in any case, while with 'impose+' it
wants to install it in some of the cases. None of 'paw', 'paw++' nor 'impose+'
are installed in my system, so I don't think that they should behave different
and I don't understand at first glance why there is a difference with the case
of 'paw*', where 'upgrade' didn't cause any action while 'dist-upgrade' did
while in 'impose+' both 'upgrade' and 'dist-upgrade' do perform actions.
Perhaps it has to do with the number of packages that would be broken, upgraded,
etc.
2004-11-13 16:28 Dan Jacobson:
Subject: show returns 0 always and doesn't say anything bad
Also,
$ aptitude show no_such_package; echo $?
0
$ apt-cache show no_such_package; echo $?
W: Unable to locate package no_such_package
E: No packages found
100
This is fine now:
------------------------------
# aptitude show no_such_package; echo $?
E: Unable to locate package no_such_package
255
# apt-cache show no_such_package; echo $?
N: Unable to locate package no_such_package
E: No packages found
100
------------------------------
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
