Hi,

now that d-i no longer uses/installs discover, should we turn it
into empty packages?

I don't know of any way of removing packages on upgrades from users
systems, but at least the packages could become empty themselves.

I imagine this is a better solution than a straightforward RM from
unstable, as otherwise users will have these packages installed
forever - and they contain files in /lib etc.

Chris

[Chris Hofstaedtler]

Perhaps we can turn them into empty packages, add a description
specifying that they are transitional packages, and in the next release
add a conflict from a often installed package on these transitional
packages to get them removed?  Or will it work to let the transitional
discover package depend on some other package first, and then let the
other package conflict with discover in the next release?  Personally I
believe isenkram-cli can take over for discover, I wrote it to take over
its task, and would be happy to add a conflict when the time is right.

<https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#obsolete>
<https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages>

Why not just remove the package from the archive (and mention it in
release notes) ?
How will it be different from any other obsolete package ?

* Pascal Hambourg <pascal@plouf.fr.eu.org> [240822 11:36]:

It is different from almost all other packages by virtue of
a) being installed on all systems installed using d-i
b) there is no direct replacement for it that would take care of
replacing the binary packages on a default install.

Chris

[Chris Hofstaedtler]

Which properties are you looking for in such direct replacement?  I
could adjust isenkram-cli if it make sense, to match such properties.

additionally introduce new ones. Thus a replacement would have to
`Conflicts:` + `Replaces:` the existing packages, _and_ also already
be on most systems. Adding new packages which are used by few people
is IMO a non-starter.

So we could clearly have, lets say, base-files Conflicts:+Replaces:
the packages, but that seems a distant solution in a far away
package that can break in ways we don't want.

Making the existing packages empty, including ensuring they clean up
the conffiles, would leave systems in an almost clean state, which
is also harmless. If the packages end up being overridden to section
`oldlibs`, the existing instructions in the manual should also be
good for cleaning them up for users that care enough.

What I want is that we do the right thing by default for most users,
without them having to do stuff additionally.

Best,
Chris

[Chris Hofstaedtler]

My point of view is that discover was created with the purpose of
proposing the relevant packages for installation based on the present
hardware on a computer, and my suggestion to look into isenkram-cli come
from the fact that this package was created to cover the same purpose.
I also believe this goal is a valuable one to fulfill in Debian, and
that dropping the feature is doing those installing Debian a disservice.
Removing discover without adding a functional replacement is thus to me
not an advantage, but a missed opportunity to bring better hardware
handling to everyone currently having dsicover.

I am not aware of any other packages than discover and isenkram in
Debian providing information on which package to install for the
relevant hardware in or connected to a Debian computer.  Sadly discover
have not been maintained for a while now, and thus in my biased opinion
only isenkram provide the feature well today.  d-i provide a
reimplementation of isenkram-autoinstall-firmware at install time, while
isenkram provide it also after installation, in addition to the more
comprehensive handling of hardware related packages that are not
firmware related.