[Freeipa-devel] Build system refactoring - design document
Petr Vobornik
pvoborni at redhat.com
Tue Oct 11 13:47:40 UTC 2016
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
More information about the Freeipa-devel
mailing list