-----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 > [email protected] > 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----- _______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
