Re: [Freeipa-devel] Build system refactoring - design document
On 11.10.2016 15:47, Petr Vobornik wrote: > 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. Fine with me. Please formulate your requirements to user stories and add them to: http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories I will look at them after that. -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] Build system refactoring - design document
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
Re: [Freeipa-devel] Build system refactoring - design document
On Fri, Oct 07, 2016 at 11:56:26AM +0200, 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 sure who exactly is the tester -- is it QE team, developer testing someone else's patch, or someone else who just wants to try a particular build? I'd often like to test a build but I'd like to use yum repo for that, not building locally with "make rpms" because I'd likely need additional dependencies installed for that and I'll likely need some runtime dependencies as well. IMO, QE teams shouldn't be building rpms themselves either, they should consume nightly/snapshot builds produced by engineering, either automatically or manually. Could we add some high level goals for the refactoring effort, and add a goal of having repoclosure'd yum repo for master and interesting branches / pull requests? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On ti, 11 loka 2016, Petr Spacek wrote: On 11.10.2016 10:04, Jan Cholasta wrote: On 11.10.2016 09:36, Petr Spacek wrote: On 11.10.2016 09:00, Jan Cholasta wrote: Hi, On 7.10.2016 11:56, 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. 1) There should be a --with-python switch to select the version of Python to use in our command line tools and/or during build. The default would be "python", i.e. the default Python interpreter found in the path. Okay. Can we pick some descriptive name? --with-default-python or --with--python? I think that it would be confusing if we had just --with-python --with-python2 --with-python3 If the default values are "python", "python2", "python3" respectively, I don't These need to be full paths. I hope that some autoconf detection logic will help with autodetection. think it would be confusing, since most of the time you only need to specify --with-python, if anything. Okay, let me be explicit: It *is* confusing for me. Would you be okay with --with-default-python ? Do we even need --with-python2 and --with-python3? I think they would only make sense if you had multiple Python minor versions installed and wanted to make packages for all of them. AFAIK autoconf-style is to provide these for options where path to external binary is needed. I would like to keep these conventions to avoid NIH syndrome in the new build system. Also, --without-python2/--without-python3 is needed anyway to disable this part of build on systems without Python X version. I want to keep this explicit (as with any other optional part of the build). Why so complex? Allow --with-python to be specified multiple times and enable all python versions that resolve through --with-python specified executables: --with-python=/bin/python2 --with-python=/bin/python3 would enable both Python 2 and Python 3. Specifying none will enable default version found on the system. Specifying one will enable explicitly only one. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On 11.10.2016 10:04, Jan Cholasta wrote: > On 11.10.2016 09:36, Petr Spacek wrote: >> On 11.10.2016 09:00, Jan Cholasta wrote: >>> Hi, >>> >>> On 7.10.2016 11:56, 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. >>> >>> 1) There should be a --with-python switch to select the version of Python to >>> use in our command line tools and/or during build. The default would be >>> "python", i.e. the default Python interpreter found in the path. >> >> Okay. Can we pick some descriptive name? >> >> --with-default-python >> or >> --with--python? >> >> I think that it would be confusing if we had just >> --with-python >> --with-python2 >> --with-python3 > > If the default values are "python", "python2", "python3" respectively, I don't These need to be full paths. I hope that some autoconf detection logic will help with autodetection. > think it would be confusing, since most of the time you only need to specify > --with-python, if anything. Okay, let me be explicit: It *is* confusing for me. Would you be okay with --with-default-python ? > Do we even need --with-python2 and --with-python3? I think they would only > make sense if you had multiple Python minor versions installed and wanted to > make packages for all of them. AFAIK autoconf-style is to provide these for options where path to external binary is needed. I would like to keep these conventions to avoid NIH syndrome in the new build system. Also, --without-python2/--without-python3 is needed anyway to disable this part of build on systems without Python X version. I want to keep this explicit (as with any other optional part of the build). >> Besides that, I would make --with-default-python to accept either "2" or "3" >> (and thus use path specified by --with-python? option). >> >> >> >>> 2) There is --with-pylint, --with-jslint, but no --with-po-validate. >> >> Let me clarify: I plan to use --with for things which have paths or other >> parameters, --enable for booleans. > > I see, that was not clear to me, I confused the two. > >> >> Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is >> calling script ../../ipatests/i18n.py which is in IPA source tree anyway. >> >> Do you want to have a --enable/--disable switch for these PO checks? > > Not really. > >> >> >>> 3) I would prefer that if pylint (or jslint or python-polib) is not >>> installed >>> the build would fail instead of silently skipping the lint. Let it be a >>> wilful >>> decision of the packager whether to run the lint or not. >> >> Yes, that is my intent. It will not skip anything automatically. > > Right. > >> >> >> >>> 4) It is explicitly stated that I can turn off features using >>> --without-feature. But how do I disable building server components? >> >> I've added explicit mention of --disable-feature: >> http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring&type=revision&diff=14311&oldid=14310 >> > > Thanks. > >> >> 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. >>> >>> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it >>> is written only to ipapython/version.py: >>> >>> $ git grep -E '\bIPA_VENDOR_VERSION\b' >>> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) >>> Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" >>> ipapython/version.py >> >> My bad, I should write 'IPA*VERSION*'. >> >> Especially unconditional write to version.m4 is problematic but unconditional >> writes to other files slows things as well, just not that much. > > Could this be worked around by writing into a temporary file, comparing it > with the real file and mv'ing the temporary file over the real file only if > the differ? Right now IPA_VERSION_IS_GIT_SNAPSHOT is always appends timestamp to the string so the move would happen always ... This is why I'm trying to understand where the versions are used and if they really have to change at every (devel) build. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Cont
Re: [Freeipa-devel] Build system refactoring - design document
On 11.10.2016 09:36, Petr Spacek wrote: On 11.10.2016 09:00, Jan Cholasta wrote: Hi, On 7.10.2016 11:56, 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. 1) There should be a --with-python switch to select the version of Python to use in our command line tools and/or during build. The default would be "python", i.e. the default Python interpreter found in the path. Okay. Can we pick some descriptive name? --with-default-python or --with--python? I think that it would be confusing if we had just --with-python --with-python2 --with-python3 If the default values are "python", "python2", "python3" respectively, I don't think it would be confusing, since most of the time you only need to specify --with-python, if anything. Do we even need --with-python2 and --with-python3? I think they would only make sense if you had multiple Python minor versions installed and wanted to make packages for all of them. Besides that, I would make --with-default-python to accept either "2" or "3" (and thus use path specified by --with-python? option). 2) There is --with-pylint, --with-jslint, but no --with-po-validate. Let me clarify: I plan to use --with for things which have paths or other parameters, --enable for booleans. I see, that was not clear to me, I confused the two. Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is calling script ../../ipatests/i18n.py which is in IPA source tree anyway. Do you want to have a --enable/--disable switch for these PO checks? Not really. 3) I would prefer that if pylint (or jslint or python-polib) is not installed the build would fail instead of silently skipping the lint. Let it be a wilful decision of the packager whether to run the lint or not. Yes, that is my intent. It will not skip anything automatically. Right. 4) It is explicitly stated that I can turn off features using --without-feature. But how do I disable building server components? I've added explicit mention of --disable-feature: http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring&type=revision&diff=14311&oldid=14310 Thanks. 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. How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it is written only to ipapython/version.py: $ git grep -E '\bIPA_VENDOR_VERSION\b' Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" ipapython/version.py My bad, I should write 'IPA*VERSION*'. Especially unconditional write to version.m4 is problematic but unconditional writes to other files slows things as well, just not that much. Could this be worked around by writing into a temporary file, comparing it with the real file and mv'ing the temporary file over the real file only if the differ? -- Jan Cholasta -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On ti, 11 loka 2016, Petr Spacek wrote: On 11.10.2016 09:00, Jan Cholasta wrote: Hi, On 7.10.2016 11:56, 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. 1) There should be a --with-python switch to select the version of Python to use in our command line tools and/or during build. The default would be "python", i.e. the default Python interpreter found in the path. Okay. Can we pick some descriptive name? --with-default-python or --with--python? I think that it would be confusing if we had just --with-python --with-python2 --with-python3 --with-python=/path/to/python.binary is enough. We have the same in Samba where a secondary build against another python interpreter is regulated with '--extra-python' pointing to the Python's executable. Besides that, I would make --with-default-python to accept either "2" or "3" (and thus use path specified by --with-python? option). I don't think we need --with-default-python=2|3 at all. Once you have a Python binary, you can discover the flavor in the code: $ python -c 'import sys; print sys.version_info.major' 2 -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On 11.10.2016 09:00, Jan Cholasta wrote: > Hi, > > On 7.10.2016 11:56, 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. > > 1) There should be a --with-python switch to select the version of Python to > use in our command line tools and/or during build. The default would be > "python", i.e. the default Python interpreter found in the path. Okay. Can we pick some descriptive name? --with-default-python or --with--python? I think that it would be confusing if we had just --with-python --with-python2 --with-python3 Besides that, I would make --with-default-python to accept either "2" or "3" (and thus use path specified by --with-python? option). > 2) There is --with-pylint, --with-jslint, but no --with-po-validate. Let me clarify: I plan to use --with for things which have paths or other parameters, --enable for booleans. Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is calling script ../../ipatests/i18n.py which is in IPA source tree anyway. Do you want to have a --enable/--disable switch for these PO checks? > 3) I would prefer that if pylint (or jslint or python-polib) is not installed > the build would fail instead of silently skipping the lint. Let it be a wilful > decision of the packager whether to run the lint or not. Yes, that is my intent. It will not skip anything automatically. > 4) It is explicitly stated that I can turn off features using > --without-feature. But how do I disable building server components? I've added explicit mention of --disable-feature: http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring&type=revision&diff=14311&oldid=14310 >> 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. > > How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it > is written only to ipapython/version.py: > > $ git grep -E '\bIPA_VENDOR_VERSION\b' > Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) > Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" > ipapython/version.py My bad, I should write 'IPA*VERSION*'. Especially unconditional write to version.m4 is problematic but unconditional writes to other files slows things as well, just not that much. -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] Build system refactoring - design document
Hi, On 7.10.2016 11:56, 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. 1) There should be a --with-python switch to select the version of Python to use in our command line tools and/or during build. The default would be "python", i.e. the default Python interpreter found in the path. 2) There is --with-pylint, --with-jslint, but no --with-po-validate. 3) I would prefer that if pylint (or jslint or python-polib) is not installed the build would fail instead of silently skipping the lint. Let it be a wilful decision of the packager whether to run the lint or not. 4) It is explicitly stated that I can turn off features using --without-feature. But how do I disable building server components? 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. How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it is written only to ipapython/version.py: $ git grep -E '\bIPA_VENDOR_VERSION\b' Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" ipapython/version.py Honza -- Jan Cholasta -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On 07.10.2016 12:56, 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? If you mean build system -wise, there isn't anything that I need, at least if you migrate to autotools which sounds great. This is the debian/rules of the current package, so if you'll have a proper 'make clean' (as suggested already) and a one-pass build then that's pretty much what I'd "need". https://anonscm.debian.org/cgit/pkg-freeipa/freeipa.git/tree/debian/rules -- t -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On 7.10.2016 12:59, Martin Basti wrote: > > > On 07.10.2016 11:56, 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! >> > > Thank you for nice design, > > 1) > I'd like to have make clean as well (we have it there now, but I don't think > that it works well) I've added clean to the list. In general, we should get all targets listed in https://www.gnu.org/software/automake/manual/html_node/Standard-Targets.html "for free" (if we do it right). > 2) > Pylint: > > currently we have (almost) python2/3 compatible code so what is the reason to > have python2 and python3 separated checks? Pylint is doing that at once I'm fine with just one pylint. Design updated: http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration Thank you for clarification! -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On 07.10.2016 11:56, 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! Thank you for nice design, 1) I'd like to have make clean as well (we have it there now, but I don't think that it works well) 2) Pylint: currently we have (almost) python2/3 compatible code so what is the reason to have python2 and python3 separated checks? Pylint is doing that at once -- 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
Re: [Freeipa-devel] Build system refactoring - design document
On 7.10.2016 11:56, 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! Also, if you are packager or tester, please describe your requirements/use-cases/user stories/whatever so I can design the system to suit your needs. I've tried to capture developer's needs to http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories Please let me know if you are okay with that or if it needs corrections. Thank you for your time! -- Petr^2 Spacek -- 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
[Freeipa-devel] Build system refactoring - design document
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! -- Petr^2 Spacek -- 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
