On Wednesday, June 14, 2017 11:38:38 PM CEST Till Maas wrote:
On Wed, Jun 14, 2017 at 04:20:25PM +0200, Pavel Raiskup wrote:
> On Tuesday, June 13, 2017 2:26:33 PM CEST Petr Pisar wrote:
> > On 2017-06-13, Pavel Raiskup <praiskup(a)redhat.com> wrote:
> > >> vim-syntastic praiskup 38
> > >> weeks ago
> > >
> > > Please don't remove this set of vim-syntastic* packages, there's
> > > nothing to do about this. Once we have fixed release engineering
> > > processes [1] that allow me to ExcludeArch/ExclusiveArch particular
> > > **sub**packages, I'll do so. Thanks!
> > >
> > > [1]
https://pagure.io/pungi-fedora/issue/87
> > >
> > perl-Alien-ROOT is the same case <
https://pagure.io/releng/issue/6359>.
> > The package is fine, but releng scripts cannot deal with it.
>
> It is really unfortunate...
>
> ... so because only one particular subpackage (which otherwise perfectly
> working, noarch thingy) can't have satisfied dependencies on only one of
> many supported architectures -> are going to drop the entire package (all
> subpackages) from Fedora, I mean entirely?
>
> Till, what's the action plan for this? Will you update the
> removal-candidate-list somehow?
Given the current limitations of our tooling I understand that the
corect thing to do would be to:
1) make vim-syntastic a not-noarch package
2) Use %ifarch/%ifnarch conditionals to enable/disable subpackages depending on the
arches they are properly supported/not-supported.
Unfortunately this means extra work for you but it seems to be the work
that is required for packaging vim-syntastic and providing a user
experience without any broken dependencies in our stable release.
I agree that it would be nicer to be able to just make the package
noarch and just do not ship the subpackages that are not supported on
the respective arch but I do not see how we will get there until the F26
final release.
Meh, it wouldn't hurt anyone if we shipped not-installable "leaf" noarch
package, based on "whitelist" e.g. (only untill we have a fix for the tooling).
But I would be OK with this solution - if this idea was baked into guidelines
first. Is it realistic to ratify new guidelines paragraph for this issue before
F26?
That's because (a) switching 'noarch' to arch-specific package is really
cumbersome and misleading, and some people might refuse to even think about it
(as I did, I considered this unacceptable at the beginning). (b) Also we need
to have some banner for the people who take care of the tooling -- when you say
in guidelines that the noarch->arch-dependent switch is temporary hack, somebody
might be motivated enough to fix the issue finally.
Pavel