On (24/06/14 09:03), Jakub Hrozek wrote:
On Fri, Jun 13, 2014 at 11:26:47PM +0300, 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?
>
> >>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.
>
> >>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.
+1
If the CI would yell at me when there is a difference between spec file
and the list (which we need to maintain for Debian anyway), I'm fine
The right approach will be to have upstream version of debian-specific files.
We can try to generate file with spec2deb (not tested)
or maintain upstream version of
http://anonscm.debian.org/gitweb/?p=pkg-sssd/sssd.git;a=blob;f=debian/con...
We have a member in team with debian packaging experiences :-)
LS