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@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
