[Aptitude-devel] Congratulations on a major release and some queries -

[Manuel A. Fernandez Montecelo]

2016-04-23 00:54 shirish शिरीष:
>Dear Manuel A. Fernandez Montecelo and all and any existing as well as
>previous aptitude maintainers,
>
>Congratulations and kudos for a new major release. I did have a brief
>look at the changes mentioned in changelog.Debian.gz as well as
>/usr/share/aptitude/news and mostly the changes seem to be about being
>conservative and keeping packages in (in respect of solutions shown to
>users) rather than destructive ones. These I probably suspect are to
>when packages are in the transitions phase
>https://release.debian.org/transitions/ in unstable or/and testing as
>well as when upgrading from one stable release to the other (the big
>ones).
>
>Any solution which doesn't scare users into thinking they might end in
>an unusable desktop state at all times and especially when they try
>doing dist-upgrade is very welcome :) I suspect that is where you went
>through this, am I right ?

Yes, this is the idea.


>I am curious about some of the things though. For instance why is news
>at /usr/share/aptitude/news rather than
>/usr/share/doc/aptitude/NEWS.Debian.gz . I did see that
>/usr/share/doc/aptitude/NEWS is also present which is symlinked to
>/usr/share/aptitude/news but don't understand the reasons for having
>both. There should either be /usr/share/doc/aptitude/NEWS or
>/usr/share/doc/aptitude/NEWS.Debian.gz . Just having both confuses
>users and more so when NEWS.Debian.gz just has information on a single
>release.  Don't understand the need for that seperate NEWS.Debian.gz
>unless you want to highlight the breakage that happened in the 0.6.1
>release for all time.

NEWS.Debian.gz is shown e.g. with apt-listchanges, really major changes
requiring users to pay attention to changes in behaviour, while
"upstream"'s NEWS is like a changelog.


>I haven't been able to quite understand the changes you have made with
>re-installation and have never been sure how it actually works.
>
>For instance. here are two versions of the mpv package in the repo.
>
>[$] apt-cache policy mpv
>
>mpv:
>  Installed: 0.14.0-1+b2
>  Candidate: 0.14.0-1+b2
>  Version table:
> *** 0.14.0-1+b2 100
>          1 http://httpredir.debian.org/debian unstable/main amd64 Packages
>        100 /var/lib/dpkg/status
>     0.14.0-1+b1 600
>        600 http://httpredir.debian.org/debian testing/main amd64 Packages
>
>Now from what little I know, I cannot do
>
>sudo aptitude reinstall mpv=0.14.0-1+b2 at least this was not allowed
>or aptitude disregarded version information and more often than not
>would install packages from testing (as I have a testing base rather
>than unstable.)  Could you elaborate on that ?

The changes related with reinstall in the current version are not
related with how the versions can be installed.

If you want to install 0.14.0-1+b1 you should do an "aptitude install
mpv=0.14.0-1+b1", since it's an change of version like an upgrade
(actually a downgrade).

reinstall is only for reinstalling the same version of the package.


>Lastly, and it has nothing to do with apt (and aptitude), actually it
>does but in a round-about way, could you look at #80123 although I
>suspect you already know that bug-report as you too would have been
>hit by downloading a big package upgrade and knowing that a severe bug
>is with that specific release and found yourself to be a little
>annoyed by not having that information before download commences.

I don't use apt-listbugs and I didn't know anything about the bug
report.  aptitude cannot support this without support in libapt (which I
don't plan to implement, if that's the question).


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>