Proposed as a Blocker and Freeze Exception for 27-final by Fedora user jvanek using the blocker tracking app because:

 The update from current packages to future packages would not be easily possible

What exactly do you mean by "not easily possible"? And how does it affect current F27 users, who already use java9?

(In reply to Kamil Páral from comment #2)
> What exactly do you mean by "not easily possible"? And how does it affect
> current F27 users, who already use java9?

Nobody does that :) Isn't it beta, so you "accept your fate" (literally) ?
Current users of jdk9 in f27 (and only those) will need to remove jdk9 and install it again.
 
Issue is, that two directories changed from directory to symlik. That is something RPM really dont like. The only solution is manual pretrans mv which I would like to avoid. 

I will probably add conflicts with its previous release to fail transaction check correctly.

Discussed at blocker review meeting [1]:

RejectedBlocker - this bug doesn't violate any criterion. The reporter should contact fesco or packaging sig to ask about this change; after their decision we will consider the FE status.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-10-09/


Personally, I feel like these changes can be done in Rawhide only. But please ask on packaging mailing list and/or FESCo ASAP, so that it's clarified and we can grant FE or not.

Hi! Thanx!

I think rawhde do not chnage the wind. As It would break in f27->f28 update:( So sooner the better.

I believe there's a way how to do incompatible changes during system upgrade, isn't it? Like the time when UsrMove was performed. Either way, it's really important to discuss the packaging team in this scenario. Please let us know how it turned out, thanks. If packaging folks or FESCo tells you this is best done in F27 ASAP, we'll definitely consider that.

posted: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/F2PMT36KTVIIBCSPVSHCFJQZKEY6VR6R/

udpdate: https://bodhi.fedoraproject.org/updates/FEDORA-2017-21a4f48b7d

(In reply to jiri vanek from comment #8)
> udpdate: https://bodhi.fedoraproject.org/updates/FEDORA-2017-21a4f48b7d

depending on this: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e1360eef16

(In reply to jiri vanek from comment #7)
> posted:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> thread/F2PMT36KTVIIBCSPVSHCFJQZKEY6VR6R/

Not much interest:(

Upgrade now fails in F27 Beta:

# dnf upgrade
Last metadata expiration check: 1:12:25 ago on Mon Oct 16 15:15:08 2017.
Dependencies resolved.
=================================================================================================================================================================
 Package                                         Arch                           Version                                     Repository                      Size
=================================================================================================================================================================
Upgrading:
 java-9-openjdk-headless                         x86_64                         1:9.0.0.181-7.fc27                          fedora                          41 M

Transaction Summary
=================================================================================================================================================================
Upgrade  1 Package

Total download size: 41 M
Is this ok [y/N]: y
Downloading Packages:
java-9-openjdk-headless-9.0.0.181-7.fc27.x86_64.rpm                                                                              5.3 MB/s |  41 MB     00:07    
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                            4.9 MB/s |  41 MB     00:08     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Running scriptlet: java-9-openjdk-headless-1:9.0.0.181-7.fc27.x86_64                                                                                       1/1 
  Preparing        :                                                                                                                                         1/1 
  Upgrading        : java-9-openjdk-headless-1:9.0.0.181-7.fc27.x86_64                                                                                       1/2 
Error unpacking rpm package java-9-openjdk-headless-1:9.0.0.181-7.fc27.x86_64
Error unpacking rpm package java-9-openjdk-headless-1:9.0.0.181-7.fc27.x86_64
error: unpacking of archive failed on file /usr/lib/jvm/java-9-openjdk-9.0.0.181-7.fc27.x86_64/conf: cpio: File from package already exists as a directory in system
java-9-openjdk-headless-1:9.0.0.181-7.fc27.x86_64 was supposed to be installed but is not!
  Verifying        : java-9-openjdk-headless-1:9.0.0.181-7.fc27.x86_64                                                                                       1/2 
java-9-openjdk-headless-1:9.0.0.181-1.fc27.x86_64 was supposed to be removed but is not!
  Verifying        : java-9-openjdk-headless-1:9.0.0.181-1.fc27.x86_64                                                                                       2/2 

Failed:
  java-9-openjdk-headless.x86_64 1:9.0.0.181-7.fc27                                                                                                              

Error: Transaction failed

*** Bug 1503211 has been marked as a duplicate of this bug. ***

Yes. It is supposed to fail.
It was mentioned in release note for the package.  That you cannot simply update, but must remove and install.
I know it was not nice, but it was the only time to do so. Please accept m apologise. But I believe it was for the best. 

The package went to stable before final freeze. Closing

Jiri, I believe you should've asked for a FESCo exception and pushing this stable without it was not a correct thing to do.

I agree with Kamil, this was a very bad call. There *were* replies to your mailing list thread, they just suggested something you don't "like". Packaging for a shared project cannot *only* be about doing things you "like".

I'm going to explicitly escalate this to FPC.

https://pagure.io/packaging-committee/issue/721

(In reply to jiri vanek from comment #13)
> Yes. It is supposed to fail.
> It was mentioned in release note for the package.  That you cannot simply
> update, but must remove and install.
> I know it was not nice, but it was the only time to do so. Please accept m
> apologise. But I believe it was for the best. 

You gave no reason why you couldn't do the change without breaking updates and there is a documented working solution. This is unacceptable, even in rawhide.

> The package went to stable before final freeze. Closing

It shouldn't have.

I'd also argue that the java-9-openjdk package doesn't follow the Packaging Guidelines and shouldn't have passed review as-is. I added more detailed comments in the review (bug 1443076).

(In reply to Dominik 'Rathann' Mierzejewski from comment #17)
> (In reply to jiri vanek from comment #13)
> > Yes. It is supposed to fail.
> > It was mentioned in release note for the package.  That you cannot simply
> > update, but must remove and install.
> > I know it was not nice, but it was the only time to do so. Please accept m
> > apologise. But I believe it was for the best. 
> 
> You gave no reason why you couldn't do the change without breaking updates
> and there is a documented working solution. This is unacceptable, even in
> rawhide.


I Agree that this would be unacceptable for released software. But for unreleased? What reason then would have testing, beta and rawhide??
> 
> > The package went to stable before final freeze. Closing
> 
> It shouldn't have.

(In reply to Dominik 'Rathann' Mierzejewski from comment #18)
> I'd also argue that the java-9-openjdk package doesn't follow the Packaging
> Guidelines and shouldn't have passed review as-is. I added more detailed
> comments in the review (bug 1443076).

Thank you. Will reply there.

(In reply to Adam Williamson from comment #15)
> I agree with Kamil, this was a very bad call. There *were* replies to your
> mailing list thread, they just suggested something you don't "like".
> Packaging for a shared project cannot *only* be about doing things you
> "like".
> 
There were two replies. Non of them was stop-show. its not "I like". The case is nasty. Jdk9 had really small audience and no footprint at all at that moment.
Have you seen the sriplets jdk carry on? All of them come with similar change. So I'm very reluctant to add any more scriplets  if there is way around.

The way around in this case to make change in package, which was never in stable release. According to bug rate on this topic, my guess on extremly low usage was correct.

"Have you seen the sriplets jdk carry on? All of them come with similar change. So I'm very reluctant to add any more scriplets  if there is way around."

But there *is* no 'way around'. What you have shipped is a buggy package. It's not really acceptable to ship buggy packages purely because you say - with no actual *justification* - that you don't want scriptlets in the package. You haven't actually explained what is you have against scriptlets - you've said "nor do I wont to scriplet the issue out" and "Have you seen the sriplets jdk carry on? All of them come with similar change. So I'm very reluctant to add any more scriplets" but you haven't said *why*. Especially given that the packaging guidelines specifically instruct you to include scriptlets in this case, just saying "I don't wanna" is *not* reasonable counter-argument. You need at minimum to cite some specific reason why there would be a problem with including the scriptlets in the package.