On 10/07/2016 11:56 AM, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management > > I'm not an FreeIPA packager so I might miss some important thing which needs > to be configurable. > > > Also, I would appreciate ideas how to handle build versioning: > http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning > > My main questions are: > * What is triggering IPA upgrade? > * Would it be sufficient to bump release in RPM? (I mean - theoretically. > Could the code be modified to detect this?) > > Here I'm trying to avoid unnecessary rebuilds caused by changes to > IPA_VENDOR_VERSION during each build. > > > Timo, what can I do to help you with packaging for Ubuntu/Debian? > > Dream big, even wild ideas are welcome! >
I'd like to add one use case which is a prerequisite for "packager": release engineer. Currently, IPA is released by running $ make IPA_VERSION_IS_GIT_SNAPSHOT=no rpms Then tarball is copied from dist/sources to freeipa.org http://www.freeipa.org/page/Release#Building_the_sources With current code, it may be done only with: $ make tarball But it probably wasn't tested much so I'd not rely on it. What I'd like to see: Release engineer: $ make dist $ # copy tarball Packager: $ ./configure [--options] $ make install I think that this workflow is implied by "Automake: Standard Targets" but IMHO it should be specified in the design explicitly because it is a change in our process. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code