[Debian GNUstep maintainers] Misc issues with gnustep-base

[Eric Heintzmann]

Le 18/10/2017 à 12:32, Yavor Doganov a écrit :
> Eric,
>
> I found three more issues; the first two are serious:
>
> 1. In 1.24.9-1 you have tightened the dependencies for no apparent
> reason.  They were lax on purpose, to allow gradual upgrades and
> smooth library transitions.  Now that 1.25.0-1 is available in
> experimental, it can't be installed because of the tight
> dependencies.  The correct behaviour would be:
>
> - upgrade libgnustep-base-dev, gnustep-base-common,
>   gnustep-base-runtime, gnustep-base-doc
> - install libgnustep-base1.25 automatically
> - leave libgnustep-base1.24 on the system until all reverse
>   dependencies are binNMUed
> - once all of them are rebuilt, libgnustep-base1.24 will be marked for
>   automatic removal
>
> The whole point of library transitions is to allow both versions of
> the library to coexist.  The tight dependencies do not allow this.  Of
> course, it is questionable whether packages would be usable during the
> transition, since starting an app that is not yet rebuilt will load
> the old library but will also launch gdnc which will load the new
> library.  However, as agreed with (release team, mentors,
> debian-devel? -- I don't actually remember) long time ago, this is the
> lesser evil
OK, let's untighten the dependencies

> 2. The shlibs must have gnustep-base-runtime as additional dependency
> along with the library.  This is because gdnc is required to be
> present in most cases, so every rdep must depend on libgnustep-baseVER
> and gnustep-base-runtime.  The library package correctly only
> Recommends -runtime to avoid circular dependency (since -runtime
> depends on the library package anyway via ${shlibs:Depends}).
OK, let's add gnustep-base-runtime to dependencies of the the lib

>
> 3. There is a reproducibility issue for all packages shipping
> autogsdoc-generated documentation, see
> https://tests.reproducible-builds.org/debian/issues/unstable/user_in_documentation_generated_by_gsdoc_issue.html
>
> This is the result of NSUserName usage when no author is specified.  I
> plan to check the envrionment for DEB_BUILD_ARCH and assign the string
> "Debian" so that this string is always the same when building a Debian
> package.  If you have a better idea, please let me know.
OK.