Re: [Freeipa-devel] Build system refactoring - design document

2016-10-11 Thread Petr Spacek
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

2016-10-11 Thread Petr Vobornik
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

2016-10-11 Thread Jan Pazdziora
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

2016-10-11 Thread Alexander Bokovoy

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

2016-10-11 Thread Petr Spacek
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

2016-10-11 Thread Jan Cholasta

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

2016-10-11 Thread Alexander Bokovoy

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

2016-10-11 Thread Petr Spacek
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

2016-10-10 Thread Jan Cholasta

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

2016-10-07 Thread Timo Aaltonen
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

2016-10-07 Thread Petr Spacek
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

2016-10-07 Thread Martin Basti



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

2016-10-07 Thread Petr Spacek
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

2016-10-07 Thread Petr Spacek
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