[Fedora-packaging] SCL -- buildtime information

Jan Kaluža jkaluza at redhat.com
Tue Oct 8 10:55:27 UTC 2013


On 10/08/2013 09:59 AM, Vít Ondruch wrote:
> Dne 8.10.2013 09:36, Jan Kaluža napsal(a):
>> On 10/08/2013 07:18 AM, Vít Ondruch wrote:
>>> Dne 7.10.2013 22:24, Toshio Kuratomi napsal(a):
>>>> * Instead we could build for the main Fedora Repo.  If we do this, the
>>>> spec
>>>>    file, git repo name, and srpm package name all need to match.  That
>>>> means
>>>>    we'd have a separate git-level package for each package+scl
>>>> combination.
>>>>    So if we had scl-php5.6 and we needed a php and php-gettext package
>>>> for it
>>>>    we'd need separate git-level packages named scl-php5.6-php and
>>>>    scl-php5.6-php-gettext.
>>>
>>> This goes exactly against the basic premise on which SCL were build and
>>> that is: "The SCL package must be buildable from the very same .spec
>>> file into regular package as well as SCL package.".
>>
>> I'm not following SCL in Fedora, but even the first way suggested by
>> Toshio is against this basic premise. When you have another .spec file
>> in extra branch, it's not the "very same .spec file"
>
> Different branch does not mean the files are different. It is just
> different branch. You can merge, cherry-pick, etc.

Why do we want to have two branches with the same spec file in it? And 
if it's not intended to be the same, we have basically two different 
collections with the same name (and we are not building from "the very 
same spec file" in this case).

>> and I actually don't see any reason why SCL spec file should be
>> buildable as non-SCL package (unless we decide to build them from
>> "very same branch" - meaning that you would have single .spec file in
>> "f19" branch and build it twice - once as SCL and once as normal
>> package). I don't see use-case for this.
>
> There is use case. You have Ruby 1.8.7 in RHEL and you want to build
> Ruby 1.9.3 into EPEL SCL. Ruby 1.9.3 is already available in F18, so the
> only thing you have to do is rebuild it in the proper build root,
> without any change.

Hm, that presumes there will be software collections which won't be 
build in Fedora (so they won't have Fedora SCL branch), but still have 
SCL code in their spec files. If that's valid use-case, then yes.

Otherwise you could just rebuild Ruby from 1.9.3 from SCL branch.

Anyway, the problem here is that I think it's cleaner to have two 
different spec files in some cases (with and without SCL) then having 
single package with "%if 0%{?scl:1}" everywhere. You have different 
opinion probably and that's OK. I've just wanted to share my view of 
this problem :).

>>
>> I agree it could be easier to maintain the packages this way, but for
>> bigger packages like php it's just lot of extra conditionals which
>> makes the maintenance harder.
>
> Yes, I agree.
>
>>
>> If I'm right, this basic premise is SHOULD (not MUST) in current
>> guidelines.
>
> Not sure what is in current guidelines proposal and why, the basic
> premise stays. May be somebody just forgotten history and the reasons.
>
>
> Vít
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging

Jan Kaluza



More information about the packaging mailing list