So far in Copr, there is "inherited" git branch naming from Fedora's dist-git, i.e. 'f24' for fedora 24, el5 for 'epel-5' and epel7 for 'epel-7'. The chroots in Fedora Copr are named 'fedora-N-ARCH' or 'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6, shouldn't there be mag6?). But Copr is not supposed to be used by Fedora only.
The problem I internally solved/workaround-ed are RHEL chroots. Those are named 'rhel-VERSION-ARCH'. To have it done there are several patches (against dist-git, backend, and front-end packages).
The problem, for example is, that 'el6' branch is "by default" allocated for 'epel-6-ARCH' chroots, and can not be used by RHEL. There are multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).
I'm curious whether we could "rename" the existing branches to some more consistent, "future-friendly" strings. For example:
-> 'fedora/25' (the actual f25) -> 'fedora/rawhide' (the actual master) -> 'centos/7' (the actual epel7) -> 'centos/6' (the actual el6) -> 'mageia/6' (the actual mga6) -> 'epel/7' (doesn't exist yet ..) -> 'rhel/version' (exists internally ..)
For OCD like me, it would be really pretty having it "cleanly" named, but it would be also useful for 'chroot-id <-> branch-name <-> dist-tag' converting (which now requires downstream _code_ patching, not only configuration).
Also, if we used such naming, there's no need to think again what the 'master' branch is used for ... (rhel? fedora? epel?) and for the future, adding other distributions (or complements for say rpmfusion) would be easy.
I don't remember why I chose 'fedora/25' "downstream" instead of 'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I prefer '/' separator. But that basically doesn't matter.
Anyway --> is something like that acceptable upstream? I have patches for it already (this would require copying branches within existing git repositories). There is plan B: propose this patches but add options turning this behavior on/off, whatever default we'll choose.
While we are on that, could we discuss renaming from 'epel-*' to 'centos-*'? Because we don't tell the truth entirely if we claim those are epel-* chroots.
Pavel
I think that only real restriction on branch naming is in fedpkg/fedpk-copr (load_rpmdefines function). I think that's the heart of the issue. If you could provide a sane default case for parsing branch_merge variable, then we could adjust everything else (e.g. mock_chroot_name -> branch, branch -> os conversions in frontend or dist-git.conf if needed).
clime
On Wed, Sep 21, 2016 at 4:59 PM, Pavel Raiskup praiskup@redhat.com wrote:
So far in Copr, there is "inherited" git branch naming from Fedora's dist-git, i.e. 'f24' for fedora 24, el5 for 'epel-5' and epel7 for 'epel-7'. The chroots in Fedora Copr are named 'fedora-N-ARCH' or 'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6, shouldn't there be mag6?). But Copr is not supposed to be used by Fedora only.
The problem I internally solved/workaround-ed are RHEL chroots. Those are named 'rhel-VERSION-ARCH'. To have it done there are several patches (against dist-git, backend, and front-end packages).
The problem, for example is, that 'el6' branch is "by default" allocated for 'epel-6-ARCH' chroots, and can not be used by RHEL. There are multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).
I'm curious whether we could "rename" the existing branches to some more consistent, "future-friendly" strings. For example:
-> 'fedora/25' (the actual f25) -> 'fedora/rawhide' (the actual master) -> 'centos/7' (the actual epel7) -> 'centos/6' (the actual el6) -> 'mageia/6' (the actual mga6) -> 'epel/7' (doesn't exist yet ..) -> 'rhel/version' (exists internally ..)
For OCD like me, it would be really pretty having it "cleanly" named, but it would be also useful for 'chroot-id <-> branch-name <-> dist-tag' converting (which now requires downstream _code_ patching, not only configuration).
Also, if we used such naming, there's no need to think again what the 'master' branch is used for ... (rhel? fedora? epel?) and for the future, adding other distributions (or complements for say rpmfusion) would be easy.
I don't remember why I chose 'fedora/25' "downstream" instead of 'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I prefer '/' separator. But that basically doesn't matter.
Anyway --> is something like that acceptable upstream? I have patches for it already (this would require copying branches within existing git repositories). There is plan B: propose this patches but add options turning this behavior on/off, whatever default we'll choose.
While we are on that, could we discuss renaming from 'epel-*' to 'centos-*'? Because we don't tell the truth entirely if we claim those are epel-* chroots.
Pavel _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
Top-post did not help anybody here .. I don't think I called about restrictions. I have a feeling that there will be new branches in future and even now it is not really tidy. But to be honest, I don't understand your answer, are we able to change the branch naming? And mock naming?
Pavel
On Thursday, September 22, 2016 8:04:24 AM CEST Michal Novotny wrote:
I think that only real restriction on branch naming is in fedpkg/fedpk-copr (load_rpmdefines function). I think that's the heart of the issue. If you could provide a sane default case for parsing branch_merge variable, then we could adjust everything else (e.g. mock_chroot_name -> branch, branch -> os conversions in frontend or dist-git.conf if needed).
Le 21/09/2016 à 16:59, Pavel Raiskup a écrit :
So far in Copr, there is "inherited" git branch naming from Fedora's dist-git, i.e. 'f24' for fedora 24, el5 for 'epel-5' and epel7 for 'epel-7'. The chroots in Fedora Copr are named 'fedora-N-ARCH' or 'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6, shouldn't there be mag6?). But Copr is not supposed to be used by Fedora only.
The problem I internally solved/workaround-ed are RHEL chroots. Those are named 'rhel-VERSION-ARCH'. To have it done there are several patches (against dist-git, backend, and front-end packages).
The problem, for example is, that 'el6' branch is "by default" allocated for 'epel-6-ARCH' chroots, and can not be used by RHEL. There are multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).
I'm curious whether we could "rename" the existing branches to some more consistent, "future-friendly" strings. For example:
-> 'fedora/25' (the actual f25) -> 'fedora/rawhide' (the actual master) -> 'centos/7' (the actual epel7) -> 'centos/6' (the actual el6) -> 'mageia/6' (the actual mga6) -> 'epel/7' (doesn't exist yet ..) -> 'rhel/version' (exists internally ..)
For OCD like me, it would be really pretty having it "cleanly" named, but it would be also useful for 'chroot-id <-> branch-name <-> dist-tag' converting (which now requires downstream _code_ patching, not only configuration).
Also, if we used such naming, there's no need to think again what the 'master' branch is used for ... (rhel? fedora? epel?) and for the future, adding other distributions (or complements for say rpmfusion) would be easy.
I don't remember why I chose 'fedora/25' "downstream" instead of 'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I prefer '/' separator. But that basically doesn't matter.
Anyway --> is something like that acceptable upstream? I have patches for it already (this would require copying branches within existing git repositories). There is plan B: propose this patches but add options turning this behavior on/off, whatever default we'll choose.
While we are on that, could we discuss renaming from 'epel-*' to 'centos-*'? Because we don't tell the truth entirely if we claim those are epel-* chroots.
To be completeness, you have both centos and epel repositories enabled, with centos dist tag.
Jean-Marc
Pavel _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
On Thursday, September 22, 2016 9:39:34 AM CEST Jean-Marc Liger wrote:
While we are on that, could we discuss renaming from 'epel-*' to 'centos-*'? Because we don't tell the truth entirely if we claim those are epel-* chroots.
To be completeness, you have both centos and epel repositories enabled, with centos dist tag.
Yup. That's valid argument (to some extent) to have it still named 'epel-*', thanks!
The thing is that I already have (as a copr user, not maintainer, and not yet resolved) issues with the fact that there are different packages from those in Koji's `epel-*` .. So the epel in copr is not the same epel as in koji.
I'm not sure what to do with this, could Copr finally use the same repos as Koji uses?
Pavel
Dne 21.9.2016 v 16:59 Pavel Raiskup napsal(a):
Anyway --> is something like that acceptable upstream? I have patches for it already (this would require copying branches within existing git repositories). There is plan B: propose this patches but add options turning this behavior on/off, whatever default we'll choose.
Patches against what? This originate in fedpkg and fedora dist-git. Copr-dist-git and copr-fedpkg already has some difference, but I do not want to differ even more. Imho this should be discussed with Fedora-infra and maintainer of fedpkg.
While we are on that, could we discuss renaming from 'epel-*' to 'centos-*'? Because we don't tell the truth entirely if we claim those are epel-* chroots.
??? Epel chroot does not mean RHEL. It means EPEL, which is "high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). "
On the other hand, the name "centos-*" would imply that it is just CentOS, without additional repos. Which is not true. It may have sense if we add "centos-*" beside the "epel-*", but there is no demand for that. And it will likely just confuse people.
On Friday, September 23, 2016 11:03:27 AM CEST Miroslav Suchý wrote:
Dne 21.9.2016 v 16:59 Pavel Raiskup napsal(a):
Anyway --> is something like that acceptable upstream? I have patches for it already (this would require copying branches within existing git repositories). There is plan B: propose this patches but add options turning this behavior on/off, whatever default we'll choose.
Patches against what?
Against everything which is needed to be patched. I was OK with patching Copr only to fix internal Copr instance.
This originate in fedpkg and fedora dist-git. Copr-dist-git and copr-fedpkg already has some difference, but I do not want to differ even more.
Why can't we differ? Is fedora dist-git ever going support all the repos Copr will support?
Then maybe it is not the correct approach for Copr, because fedpkg is strictly Fedora oriented, and Copr should not be.
The plan B is about optional feature (plan A is to make it done in Fedora Copr similarly as is done in internal Copr). Trust me, now you basically enforce the branch naming for everybody who would consider using Copr. Changing branch layout requires downstream patching and package rebuilds.
Imho this should be discussed with Fedora-infra and maintainer of fedpkg.
I probably miss the point why this is so sensitive topic.
But I don't really plan to bother Fedora people to force them to change branching policy. Especially if I see how problematic is to even discuss this for @copr. So the answer is NO -- we'll never change that branching policy *in copr*? Because if we wanted to have this done, sooner is better...
While we are on that, could we discuss renaming from 'epel-*' to 'centos-*'? Because we don't tell the truth entirely if we claim those are epel-* chroots.
??? Epel chroot does not mean RHEL. It means EPEL, which is "high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). "
Agreed. Already explained in different thread.
On the other hand, the name "centos-*" would imply that it is just CentOS, without additional repos. Which is not true. It may have sense if we add "centos-*" beside the "epel-*", but there is no demand for that. And it will likely just confuse people.
Agreed. As written in different thread, can epel in Fedora copr be the same as epel in Fedora's default build system?
Pavel
Dne 23.9.2016 v 12:44 Pavel Raiskup napsal(a):
Why can't we differ?
Because it adds more maintenance overhead.
Is fedora dist-git ever going support all the repos Copr will support?
Ideally this should be config driven. And Fedora and Copr should have the same code, just different configs.
On Friday, September 23, 2016 1:30:41 PM CEST Miroslav Suchý wrote:
Dne 23.9.2016 v 12:44 Pavel Raiskup napsal(a):
Why can't we differ?
Because it adds more maintenance overhead.
ATM there is maintenance overhad on our side same as on your side, IIUC. While simple patch would solve my problems, without bothering you. And, TBH, current packaging of copr as-is in Fedora is not useful to anybody else than for Fedora copr.
Is fedora dist-git ever going support all the repos Copr will support?
Ideally this should be config driven.
Thats right... ideally.
And Fedora and Copr should have the same code, just different configs.
I'm not sure what this means for me. Can you elaborate? Do I have to motivate fedpkg maintainers (is anybody from Copr team in fedpkg team?) to accept my patches to solve issue between fedora copr and redhat copr?
What I talked about is straight forward patch against your sources, I'm just curious whether you would like to have different naming for your branches, or whether I need to make it optional.
Pavel
copr-devel@lists.fedorahosted.org
-
Jean-Marc Liger -
Michal Novotny -
Miroslav Suchý -
Pavel Raiskup