[Debian GNUstep maintainers] Misc issues with gnustep-base
Eric Heintzmann
heintzmann.eric at free.fr
Wed Oct 18 23:23:06 UTC 2017
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.
More information about the pkg-GNUstep-maintainers
mailing list