[Piuparts-devel] Bug#873733: RFC: whitelist isa-support to allow it to abort installation?

[Adam Borowski]

On Sat, Dec 02, 2017 at 08:32:49PM +0100, Julien Cristau wrote:
> On Mon, Sep 18, 2017 at 11:55:28 +0000, Holger Levsen wrote:
> 
> > Dear release team,
> > 
> > I would like to ask you for your opinion on "#873733: please whitelist
> > isa-support so it's allowed to fail piuparts testing" to prevent piuparts
> > results from blocking isa-support's migration to testing. (See the (short)
> > bug log for details.)
> > 
> > I still think that's the right thing to do (and thus to close #873733 as
> > wontfix), but I also think it's up to you to decide, not the piuparts
> > maintainers.
> > 
> I personally think that package should not exist, I can't see a way in
> which depending on it wouldn't be a RC bug.

Then do you insist to file RC bugs on every package that for some reason
can't work on baseline ISA?  When upstream doesn't support that and
porting is too hard to do ourselves (rust, chromium), no machine can
possibly run that software (pcsx2 on CPUs slower than the console emulated,
all known ROMs for it are games thus useless at 1/20 the speed), or merely
because doing so would be a pure waste of maintainers' time (scientific
stuff on slowest hardware)?

I do consider all of that valid use cases, despite not working at some
machines that share the same base architecture.  isa-support merely makes
the failure nicer.

A better solution has been proposed (doing so inside apt), but it hasn't
been implemented yet.  Thus, I believe that the current approach is better
than doing nothing.

The one issue raised, test failing during preinst on _upgrades_, implies an
useless package is installed, thus aborting the upgrade or making the user
remove it does no harm.


Only when (hopefully not "if") the apt-based solution (or something else) is
implemented, it'd be reasonable to remove this package.  Otherwise, we'd be
merely sweeping the problem under the carpet.


For the record: because of the uncertainty whether isa-support will be kept,
there are only two packages with such a dependency (I looked only on release
archs):
  gromacs: sse2-support [i386], neon-support [armhf]
  sortmerna: sse2-support [i386]
both of which are scientific number-crunchers; a bunch more crash at
runtime.  The latter indeed need _some_ way to mark this problem.  There's
no known automated way to detect such violations: I tried disassembling all
of archive (results posted on debian-devel), but there's too many false
positives due to conditional use, which would require manual testing.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail"
⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah
⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820..."
⠈⠳⣄⠀⠀⠀⠀ (same for all links)