On (13/06/14 23:26), Nikolai Kondrashov wrote:
On 06/13/2014 10:28 PM, Lukas Slebodnik wrote:
>On (13/06/14 20:27), Nikolai Kondrashov wrote:
>>On 06/13/2014 06:52 PM, Lukas Slebodnik wrote:
>>>On (13/06/14 16:50), Lukas Slebodnik wrote:
>>>>On (13/06/14 16:49), Nikolai Kondrashov wrote:
>>>>>On 06/13/2014 03:14 PM, Lukas Slebodnik wrote:
>>>>>>On (13/06/14 14:50), Nikolai Kondrashov wrote:
>>>>>>>On 06/13/2014 02:00 PM, Lukas Slebodnik wrote:
>>>>>>>>On (13/06/14 13:40), Nikolai Kondrashov wrote:
>>>>>>>However, the fact that someone (who has different situation)
does something,
>>>>>>>doesn't mean that it's an efficient thing to do. Could
you please provide the
>>>>>>>rationale for your solution, so we can compare benefits and
drawbacks and make
>>>>>>>a rational decision? Perhaps I'm biased, or am missing
something.
>>>>>>>
>>>>>>I wrote it few times. I do not want to maintain two different list
of build
>>>>>>dependencies. The referential and only source should be spec files
in contrib
>>>>>>directory. I already proposed few solutionswhich will solve
problem for you
>>>>>> * yum-builddep
>>>>>> * obtaining dependencies from src.rpm with rpm.
>>>>>
>>>>>I'm sorry, but "I do not want" doesn't count as a
rationale, especially since
>>>>>there are other people maintaining the package as well. What are the
benefits
>>>>>of your solution for everyone? What do we win with it?
>>>>>
>>>>>Also, as I stated before, extracting dependencies from the RPM is not
the main
>>>>>problem. The main problem is unnecessary complexity.
>>>>I'm sorry but you should explain to me benefit of maintaining the same
build
>>>>dependencies on two different places.
>>>>
>>>>In near future, there will be bigger differences between rhel6, rhehl7
and
>>>>fedora. You will need to maintain very similar dependencies in CI for
rhel6
>>>>and fedora22(alias new rawhide). We already maintain them in sssd.spec.
>>>>
>>>common dependencies for rhel6 and fedora20
>>> augeas-devel autoconf automake bind-utils c-ares-devel check-devel
dbus-devel
>>> dbus-libs docbook-style-xsl doxygen findutils gettext-devel glib2-devel
>>> keyutils-libs-devel krb5-devel libcollection-devel libdhash-devel
>>> libini_config-devel libldb-devel libselinux-devel libsemanage-devel
>>> libsmbclient-devel libtalloc-devel libtdb-devel libtevent-devel libtool
>>> libxml2 libxslt m4 nspr-devel nss-devel openldap-devel pam-devel
pcre-devel
>>> pkgconfig popt-devel python-devel samba4-devel selinux-policy-targeted
>>>
>>>el6 specific:
>>> libnl-devel
>>>
>>>fc20 specific:
>>> libcmocka-devel cifs-utils-devel systemd-devel libnl3-devel
>>
>>Here is the number of commits involving BuildRequires per year:
>>
>>$ git log --format='%h %cd' -G 'BuildRequires'
contrib/sssd.spec.in |
>> cut -d' ' -f6 | sort | uniq -c
>>
>> 3 2009
>> 12 2010
>> 7 2011
>> 4 2012
>> 4 2013
>> 3 2014
>>
>>Not all of them actually add or remove dependencies, some just move them
>>around.
>>
>You can change something in spec file which will for on fedora 20, but it will
>break build on rhel6. This is not a valid argument.
Sorry, can you elaborate?
For example you can simply add "BuildRequires:
cifs-utils-devel" to the spec
file. It will work with fedora but won't on rhel6. cifs-utils-devel if not
available on rhel6. You will need to use conditions in spec file.
>>My point is, it is not worth it to make CI duplicate autoconf substitution
>this substituion is very simple.
>
>>code to generate valid .spec file, making all of the CI tests depend on it,
>>to make it necessary to debug a (complicated) .spec file and the substitution
>It is not about debugging spec file. The purpose should be to test spec
>file from sssd master on latest version of fedora and the latest
>unofficially supported version of rhel. (nowadays rhel6).
I understand that. All I'm saying is that the whole CI test suite depending
unnecessarily on complicated/fragile code (that being the .spec file and the
substitution), by means of requiring dependency installation through them at
the start, is not a good idea.
It is neither complicated nor fragile if you use
proper tools for extractions
dependencies from spec file.
The only reason why sssd.spec.in is preprocessed with configure is to avoid
duplication. The PACKAGE_VERSION is used from file version.m4. So you do not
need to remember change version in two different places (version.m4, sssd.spec)
The PACKAGE_NAME can be replaced with hardcoded string "sssd". I don't know
why
it was used in sssd.spec.in and PRERELEASE_VERSION is used only
for pre-release version which contains git hash.
>>code to run *any* CI tests in case it breaks. I think it is not worth it to
>>split package list source into two for just one distribution family, making
>>the code more confusing. IMO, it is not worth it to force users to enter extra
>>passwords, because yum-builddep cannot be trusted a sudo rule, or build srpm
>>and then rely on a kludge of feeding its dependencies to yum, increasing
>>fragility further.
>If you do not want to use yum-builddep you can use different method
>for extraction build dependencies from spec file. It will will save one typing
>of password.
>
>>I think the above is not worth avoiding adding or removing one or two package
>>names in one extra place just a couple of times a year.
>>
>It is still a duplication.
Duplication by itself is not an absolute evil. The effort required to sync
matters.
Simple duplication isn't. If you consider rhel6 situations is much
more
complicated.
>>I find it unlikely that we will suddenly need to change our
list of build
>>dependencies or conditionals often (say, 20-30 times a year). However, if it
>>happens or if it is predicted to happen, I'll implement the dependency list
>>extraction as soon as possible, because then it will be worth it.
>>
>I realised that you appended systemd-devel into DEPS_LIST for DISTRO_BRANCH
>"-redhat-*". With current version of CI script it will be impossible to test
on
>rhel6. It is a big drawback. My assumption is to use CI at least for rhel6,
>current fedora and some version of debian/ubuntu. Your current version cannot
>fulfil this requirement. It is my fault that I didn't clarify it in
>beginning of discussion.
>
>You will need to maintain different set of build dependencies for rhel6 and
>fedora 20 (or rhel7). It worth to implement dependency extraction
>from spec file now.
I agree that increased complexity of the duplicated code makes it worse.
However, as I stated before, a few conditions in addition to already present
distro family branching wouldn't hurt much. And I daresay a single condition
should be enough to tackle RHEL6 dependencies.
As I already wrote. Simple
duplication can be acceptable sometimes.
But maintaing dependencies from rhel6, rhel7, fedora in spec file and
arrays in bash is not the simple duplication.
When we discussed this with Jakub, RHEL6 didn't come up,
that's why I didn't
Maybe you didn't ask.
target it. I also didn't target the 1.11 branch yet, as it would
need its own
It is not about 1.11 branch. I meant sssd master from begginign of
discussion.
set of fixes first. Do we target RHEL6 with master? If yes, I'll
try targeting
RHEL6 and we'll see how the dependency tracking changes.
I already wrote few
times that Kevin Wright is testing sssd master on rhel6
and he found a few problems which were not catched in review.
Let's summarize.
I don't like maintaing build dependecies in two different palaces
and you don't want to extract build dependencies from spec file.
We need to find a compromise. What do you propose?
LS