Summary/Minutes from today's FESCo Meeting (2014-01-15)

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/16/2014 02:12 PM, Adam Williamson wrote:
> On Thu, 2014-01-16 at 07:39 +0100, Marcela Mašláňová wrote:
>> =================================== #fedora-meeting: FESCO
>> (2014-01-15) ===================================
>> 
>> 
>> Meeting started by mmaslano at 18:00:34 UTC. The full logs are
>> available at 
>> http://meetbot.fedoraproject.org/fedora-meeting/2014-01-15/fesco.2014-01-15-18.00.log.html
>>
>> 
.
>> 
>> 
>> 
>> Meeting summary --------------- * init process  (mmaslano,
>> 18:01:02)
>> 
>> * 1197 Procedure for suggesting/approving different Products
>> and/or WGs? (mmaslano, 18:01:58) * ACTION: mattdm will create
>> proposal for spins/secondary products (mmaslano, 18:12:00) *
>> ACTION: jreznik will help mattdm wiht proposal (invite
>> interested people...)  (mmaslano, 18:15:44)
>> 
>> * #1218 Before this starts causing us in QA serious headache
>> there should be manatory description on copr repos  (mmaslano,
>> 18:18:55) * AGREED: proposal about adding dist tag didn't pass
>> (+4,-5,0) (mmaslano, 18:44:11) * AGREED: interested parties work
>> with copr maintainer for vendor tag and description changes out
>> of band (+5,-0,0)  (mmaslano, 18:52:33)
> 
> So, in the discussion of this, the following was presented as an 
> obstacle:
> 
> 18:31:13 <notting> Requires: foo > 1.0-1.%{release} 18:31:22
> <notting> 1.0-1.fc20.copr *satisfies* that
> 
> Well, sure. But as mitr noted in passing - and everyone seemed to
> ignore - that's a terrible conditional in all sorts of ways: 
> foo-1.0-1.%(nextrelease) satisfies that conditional too, even
> though it's probably identical to foo-1.0.1.%{release} .
> 
> Does anyone have a case where %{release}.copr can cause problems
> that can't *also* be caused just by the same build having been done
> for multiple %{release}s?
> 
> In the cited case, I'd use:
> 
> Requires: foo >= 1.0-2
> 
> or something similar. In general, isn't it pretty much universally 
> accepted that you should try *really hard* to avoid the disttag
> being significant to your conditionals because it's just
> fundamentally unreliable to use it?
> 

I feel like I tried several times to communicate this exact statement
and was pretty much ignored.

I'd love to reopen this discussion, since I really do think the
%{dist} solution is the easiest and most visible way to solve this
problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLZK00ACgkQeiVVYja6o6PwcwCcCGKepX72SVQYiZdtfml2uynR
xccAoIwrvW/seZFJ2f5J29li2AP+QN8r
=4DB4
-----END PGP SIGNATURE-----