[Rpm-ecosystem] Why should Copr build service parse %name from spec file for dist-git import

[Igor Gnatenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 2017-08-29 at 12:37 +0200, Miroslav Suchý wrote:
> Reposting original message as Pavel is not approved member of this
> mailing list.
Thanks!
> 
> Dne 28.8.2017 v 17:46 Pavel Raiskup napsal(a):
> > Hi all!
> > 
> > In Copr project, we try to solve interesting question which is
> > worth
> > asking wide and experienced audience.
> > 
> > Copr service maintains it's own dist-git server;  that means that
> > each
> > build request needs to be first imported into dist-git (sources
> > uploaded
> > and spec/patches committed to git).  Then, the binary RPMs are
> > built
> > almost solely from the dist-git sources (well, since you can opt-in 
> > an
> > Internet access, and copr (imo a bit mistakenly) tries to download
> > the
> > not-yet-downloaded tarballs, this rule is not enforced).
> > 
> > Anyways, consider that you have an upstream project having specfile
> > named
> > `blah.spec`, which has inside the statement "Name: python-
> > %pypiname".
> > Copr dist-git automation downloads your project, takes this spec
> > file and
> > tries to decide "which dist-git module should I import this spec
> > file
> > into?".  So, where should we import?
> > 
> >    Option #1 -> import into blah.git (since that's blah.spec)
> >    Option #2 -> import into python-blah.git (since %name expands to
> >                 python-blah)
> >    Option #3 -> refuse to build the package
> > 
> > To be honest with you all, I'm all for #3 (but we are proven we can
> > not do
> > that, that's too restrictive and a lot of people will complain,
> > even if
> > their packages don't comply with guidelines).
> > So, I'm personally picking #1 because that's trivial and 100%
> > deterministic.  Are there any reasons to pick #2?
I definitely dislike option #2 which is currently in production. Also
it requires spec to be able to be parsed by some RPM which might be
older than required (hello weak/rich dependencies). In theory, name
also can expand differently on different versions of distros (e.g.
because of some EPEL policies, there is some macro which changes
name/paths to different one on EPEL).. It seems to be just over-
engineered without any benefit. Option #3 doesn't fit due to same
problems, but it is even worse because it is breaking builds.

So I'm all in for Option #1! Also I hope it will get versions of
packages back into COPR... Look at https://copr.fedorainfracloud.org/co
prs/g/rust/playground/build/585107/

Version: -

To me, this is just regression.
> > 
> > Pavel
> > 
> 
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

- -- 
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmlSBkACgkQaVcUvRu8
X0yFzQ/9EJke1WiGd8iMr+roRlo7ABkQwG5aIfNZ4J2eoj43t1kkKOt7A0CKWcL5
BSHccYEt4zRqPbNm+dl574xeTyDTbSq2V3HU/sNihEkaWGITxuOAybMQSNYcFNyL
AOJnLFWa/AwsQN5GL5vWuQWmnzft0BqWH+cIblWgAT0mHAWYumRd27YGJ0qxUQBP
KwCVX0cuA297S/K06yPUGRUpK4pFdAl0T0aFM/18kDN5huvJrB9mA+T4L+55VLN9
6dtPy/0gKWzKZcEphC7y2Msfm1zKsukFLjkPpwkDnybHMWgnW496904wOV6SchsL
Mv7cdoqYDYt0fAetSQCY/t46ydZlGjApwFY47Z4ZUIyg01Bo1tB18QqS3Wm1lOQU
K4Vok0Vs8JvBAESmKQH9HUx84nDFiRn9+xiS9pp/u7ShOjE+Q0JnDBwjAyPBUHGG
K9REXeocV87GPwAzXHU2pcWtj5U27Ff7eTbuS2qlJJKtIREDdAaxQK1nRr9Zr52g
zy5p5uVT/2K2BZiBhzFYwWQYV6Zq8OtG2jCfRn6lOXnOXvzrxyu3dLuOQVGRsg6g
c4Pqb9/W93ouHphrkomVS7d5OeejecUvp0dYnJe05qWXZFOwCqfON7xRc4RGjAjE
dZHkYQg+x2rOP5DarGSCT/ojlD7F2/SLx3i8k2OCnCiRVdI2M1c=
=6+/w
-----END PGP SIGNATURE-----