Hi Dirk, Am 18.10.2016 um 10:25 schrieb Dirk Müller:
I'd appreciate if you could check with the maintainer before changing links in a project that you're always pointing out that you're not maintaining, *especially* in non-Staging projects that are supposed to be stable. if you want to do a change, you're welcome to try it out in the Staging project.
There is nothing to try out in a Staging project here, this is all about creating JeOS-raspberrypi2 and JeOS-raspberrypi3 in Factory! Which conflicts by name with any Contrib projects it is deprecating, whomever may have maintained them previously. As you may have read, Guillaume and me tested out images from my home project before I flipped the switch for :Factory:ARM. Same idea for Pine64 for instance - therefore my urge to separate the packages cleanly there, so that we can get things into hardware, Base:System or whatever devel project and out of Contrib once it goes upstream.
|`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 | |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi3 | | (previously a direct _link to openSUSE:Factory:ARM) | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi2 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi3 | (previously a _link to devel:ARM:Factory:Contrib:RaspberryPi2)
I think this violates the rule that "JeOS-flavor link diff should be empty" rule.
Well, I did not create JeOS-raspberrypi2 that way. ;) And my point was about "one", not literal "JeOS".
What I would have liked to see here instead is the creation of a JeOS main package that the others linked to, e.g.
devel:ARM:Factory:Contrib:RaspberryPi2/JeOS - link to openSUSE:Factory:ARM / JeOS | ' devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 - link to devel:ARM:Factory:Contrib:RaspberryPi2 / JeOS
this way the JeOS-raspberrypi2 is empty and doesn't require a link diff and hence no "manual conflict resolution".
Good idea, if we disable the JeOS package like I did in :Contrib:HEAD. You're free to further improve things yourself, that was the goal of my original cleanups mail, but no one took action or even replied. :(
In any case the linkdiff in devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 was supposed to be temporary, and perhaps we should have just gotten rid of that link diff instead of making the setup now confusing and complex.
No, in order to have an official JeOS-raspberrypi2 in :Factory:ARM this is _not_ temporary. As is in Factory today, the image is working okay via serial, but no network or keyboard/mouse via USB; with Kernel:HEAD and Kernel:stable that gets resolved. Later today my raspberrypi2 home branch can be switched back from default to lpae. The discussion I was having with Alex is about the following: I believe the :Factory:ARM JeOS package should not contain unnecessary cruft for Contribs *whenever* there are upstream images. In that case IMO the Contribs should be abandoned as soon as the upstream images are usable - which for rpi2 will be the case with vc4 and USB. You are free to keep maintaining a Contrib package, but don't complain about the burden the duplication poses then. One could argue it wastes build power and causes confusion for users. Any link diff in the XML rather than tgz shouldn't cause problems. See also Fabian's discussion of .tgz. Alex however suggested that we might rename the downstream images after an upstream image exists, so that they can be maintained in parallel in :Factory:ARM with no link diffs in the other projects. However, I was fighting against the awkward list of IS_FLAVOR_raspberrypi3 || IS_FLAVOR_raspberrypi3_tralala, so the only sane way around it would be to reuse my $flavor vs. $flavor_type trick as for _aarch64, together with some other #define where really needed to distinguish; the kernel name can be already checked today to distinguish upstream and downstream for anything but raspberrypi3_aarch64. It just doesn't allow to distinguish Staging from non-Staging downstream, and wouldn't the whole point of Staging be to test the same, not just similar code paths? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org