[Rpm-ecosystem] Why should Copr build service parse %name from spec file for dist-git import
ignatenkobrain at fedoraproject.org
Tue Aug 29 10:55:21 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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
To me, this is just regression.
> > Pavel
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Rpm-ecosystem