Discussion:
Bug#948445: release-notes: aptitude search for not-from-Debian package has false negatives
(too old to reply)
Daniel Shahaf
2020-01-08 18:30:02 UTC
Permalink
Package: release-notes
Severity: normal
Tags: patch

Dear Maintainer,

§4.2 of the release notes¹ recommends to run «aptitude search '~i(!~ODebian)'».

I suggest to change the search pattern to «'?narrow(~i, (!~ODebian))'».

That will also catch packages that were backported directly from sid, or
packages that had been compiled with local patches (I have a few of
those), etc..

Cheers,

Daniel
(I couldn't find the repository so I'm not actually attaching a patch,
but I've set the label anyway since I'm proposing a specific change.)

¹ https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html
Andrei POPESCU
2020-01-09 06:50:01 UTC
Permalink
Post by Daniel Shahaf
Package: release-notes
Severity: normal
Tags: patch
Dear Maintainer,
§4.2 of the release notes¹ recommends to run «aptitude search '~i(!~ODebian)'».
I suggest to change the search pattern to «'?narrow(~i, (!~ODebian))'».
That will also catch packages that were backported directly from sid, or
packages that had been compiled with local patches (I have a few of
those), etc..
Indeed.

The pattern should probably not mix long form with short form.
Additionally, I don't know why the brackets were used, as far as I
understand from the docs they are not needed here / do nothing.

Based on this the shortest form would be:

aptitude search '~S~i~ODebian'

or long form:

aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

(tested on a system with locally compiled packages, but no non-Debian
packages and on a system with non-Debian packages and no locally
compiled packages).

The long form is quite self-explanatory, the short form is easier to
type.

Maybe both should be mentioned?

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Justin B Rye
2020-01-09 12:10:01 UTC
Permalink
Post by Andrei POPESCU
aptitude search '~S~i~ODebian'
Hang on, that's "installed and Debian"; we want "and non-Debian":

aptitude search '~S~i!~ODebian'
Post by Andrei POPESCU
aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
(tested on a system with locally compiled packages, but no non-Debian
packages and on a system with non-Debian packages and no locally
compiled packages).
The long form is quite self-explanatory, the short form is easier to
type.
Maybe both should be mentioned?
Remember it's currently

Below there are two methods for finding installed packages that did
not come from Debian, using either aptitude or apt-forktracer. Please
note that neither of them are 100% accurate (e.g. the aptitude example
will list packages that were once provided by Debian but no longer
are, such as old kernel packages).

$ aptitude search '~i(!~ODebian)'
$ apt-forktracer | sort

Adding a second version of the aptitude search would mean breaking it
up with a bit of extra explanation. I'd stick to one version, but I
don't know which I'd vote for.

Incidentally, I've always been slightly annoyed by that claim that
"aptitude search" isn't 100% accurate. Given that the point of
section 4.2 is to check that you're running pure Debian updated to the
latest stable point release, the fact that it tells you about legacy
kernels seems like a feature, not a bug.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Daniel Shahaf
2020-01-09 12:30:02 UTC
Permalink
Post by Justin B Rye
Post by Andrei POPESCU
The long form is quite self-explanatory, the short form is easier to
type.
Maybe both should be mentioned?
Remember it's currently
Below there are two methods for finding installed packages that did
not come from Debian, using either aptitude or apt-forktracer. Please
note that neither of them are 100% accurate (e.g. the aptitude example
will list packages that were once provided by Debian but no longer
are, such as old kernel packages).
$ aptitude search '~i(!~ODebian)'
$ apt-forktracer | sort
Adding a second version of the aptitude search would mean breaking it
up with a bit of extra explanation. I'd stick to one version, but I
don't know which I'd vote for.
If it's an either/or question, I'd vote for the long-hand spelling because it's
self-documenting. Someone who doesn't know aptitude will understand the long form
but not the short form. Someone who knows the short form will understand the long
form, but someone who doesn't know aptitude, or who only knows the long form, won't
understand the short form.

Furthermore, the docs could point to aptitude's manual, table 2.3 (in stretch;
it may have been renumbered since then).
Post by Justin B Rye
Incidentally, I've always been slightly annoyed by that claim that
"aptitude search" isn't 100% accurate. Given that the point of
section 4.2 is to check that you're running pure Debian updated to the
latest stable point release, the fact that it tells you about legacy
kernels seems like a feature, not a bug.
I agree that it is a feature, but nevertheless I think it is worth clarifying
that the results list packages that are not *today* available for download from
deb.debian.org, even if they had been available in the past, otherwise new
sysadmins who read the upgrade notes might see the kernel package in the output
and wonder if they'd been running a third party kernel.

Cheers,

Daniel

Loading...