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

>> |`- 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?


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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Reply via email to