Noarch subpackages: Upcoming Feature Freeze

[Mike Bonnet]

Toshio Kuratomi wrote:
> Florian Festi wrote:
>> Please add the packages you changed or plan to change to
>> https://fedoraproject.org/wiki/Features/NoarchSubpackages/PackagesChanged
>> Put the later in parenthesis. That way it will be easier to justify a
>> release note entry and to argue that the Feature is (at least a bit)
>> finished.
>>
> 
> I explored what would be changed if we enabled a lenient-hash check on
> these files I discovered these things:
> 
> 1) Asking reviewers to check this is pretty hard.  I'll add the steps at
> the end.

It's actually very easy to script given a few calls to the xmlrpc interface.

> 2) If reviewers are expected to do this, we need to get our user
> interface changes to rpmdiff merged upstream.  rpmlint's rpmdiff can
> only ignore timestamp.  Reviewers are going to want to have something
> like lenient-hash as well.
> 3) devhelp documentation should be marked as %doc
> 4) It might be reasonable for --lenient-hash to not check
> f.startswith('/usr/share')... I'm on the fence about this.
> 5) Most of these would have checked fine even if we used a full hash
> check instead of lenient
> 6) I discoverd a package with architecture specific differences.
> Luckily, it's just a problem in documentation.
> 
> Check results with:
> ./rpmdiff.mine -iS -iT --lenient-hash
> 
> Script attached.

I noticed your lenient-hash changes special-case .pyc and .pyo files.
It's this kind of special-casing that worries me.  What about other
types of bytecode, Java, OCaml, haskell?  What about firmwares?  What
about game datafiles?  We can't be having build system outages every
time we realize there's another special-case we need to handle in the
rpmdiff script.  I think we need to trust packagers to review their
packages and only convert to noarch where appropriate.

And if someone wants to setup a more rigorous package checker outside of
the build system and file bugs against packages with problems, noarch or
otherwise, more power to them.

> Summary:
> 23 packages listed
> 14 actually built with noarch subpackages
> 1 false positive (dbus) (files should have been marked %doc)
> 1 actual problem detected (dbus)
> 13 problem free runs
> 
> So the net change would have been one package.  Not sure if the
> maintainer would have caught the noarch vs arch specific difference as
> it is an error within documentation and they might have just added %doc
> without exploring further.
> 
> ConsoleKit: package has failed rebuild
> dbus: package has false positives that would be fixed by marking devhelp
> as %doc
>   - the dbus documentation is not arch-independent:
>     * /usr/share/devhelp/books/dbus/api/dbus-arch-deps_8h-source.html
>     * /usr/share/devhelp/books/dbus/api/group__DBusTypes.html
> em8300: no false positives
> evolution: no false positives
> evolution-data-server: No false positives
> festival: package has failed rebuild
> gdl: failed rebuild
> gmt: No false positives
> gnome-games: No false positives
> gnome-session: Latest version reverts noarch subpackage
> gtk2: No false positives
> javasqlite: not built with noarch subpackage
> kst: not rebuilt with noarch subpackage
> libtheora: no false positives
> libxcb: no false positives with --lenient-hash
>   * There is a harmless difference in two png files used in documentation
> ncl: no false positives
> nted: failed rebuild
> PackageKit: no false positives
> paraview: no false positives
> PolicyKit: no false positives with --lenient-hash
> pygobject2: hasn't been rebuilt
> pygtk2: no false positives
> xemacs: hasn't been rebuilt
> 
> Steps a reviewer would have to take:
> 1) Submit SRPM as a scratch build in koji.
> 2) Go to the package page
> 3) Go to the build page for the scratch build.
> 4) Go to the task page for the build
> 5) For at least two dissimilar architectures, click on the task for that
> arch.
> 6) For each of those tasks, download any noarch packages that were built
> (minimum 2 clicks)
> 7) run /usr/bin/rpmdiff --ignore-times on each of those pairs of packages.
> 8) For each of the many differences, decide whether the problem is an
> actual problem.
> 
> -Toshio
>