Re: F21 System Wide Change: Headless Java

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Reindl Harald (2013-11-19 23:38:21)
> 
> 
> Am 19.11.2013 20:29, schrieb Toshio Kuratomi:
> > On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote:
> >> On 11/19/2013 11:23 AM, Reindl Harald wrote:
> >>> what about having a "java-1.7.0-openjdk" meta-package obsoleting
> >>> the existing one and pulling *both* but decide if Fedora packages
> >>> if the headless is enough for dependencies and so packagers of
> >>> sevrer software can require this?
> >>>
> >>> this way you would have the least surprise for someone who does not
> >>> care about the difference and expects the full one by install
> >>> "java-1.7.0-openjdk" but make it really easy to uninstall any
> >>> graphical dependencies on servers
> >>>
> >> I agree with Reindl here, if I understand him correctly. It would
> >> certainly break upgrades in an unexpected way if an upgrade from
> >> "java-1.7.0-openjdk" suddenly stopped carrying the graphical components.
> > 
> > Note -- I think that the way the feature has things constructed would
> > achieve something similar.  The java package is essentially java-x11.  It
> > would Require: java-headless.
> > 
> > So yum install java will get you the java w/X11 support.
> > 
> >> I think it would be wise to do the same for Java. Create
> >> 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then
> >> have the 'java-openjdk-1.7.0' metapackage install both of them.
> >>

So which one of them would "Provides: java"? I'll give you several variants:

headless provides java:
    - breaks compatibility expectations of older/3rd party RPMs
    - we suddenly switch every Java package in Fedora. No opt-out

meta package provides java (and requires both headless and x11 version):
    - doesn't change anything because you can't "yum remove java-meta" or "yum
      remove java-x11" (due to packages having "requires: java" which is
      satisfied by this metapackage.  And no, packages cannot have "Requires:
      java-1.7.0-openjdk[-meta]" because there are usually multiple
      implementations of java in Fedora. We'd be changing buildrequires every
      few releases.

x11 version provides java:
    - That's basically what current proposal is with addition of metapackage.
      But I fail to see the point of metapackage in this scenario


Then again I might be completely missing the point of the metapackage but I've
been trying for past day (on and off) to come up with situation where it would
help without causing multiple other issues (or at least backward
incompatibility) and failed... So if you can explain it, or give a better
example how you think it should work: I'd love to be wrong.

> > I can see one advantage to this approach: it lets us tell packagers that
> > Requires: java should no longer be used.

I don't consider that an advantage. It breaks backward compatibility for...I
don't know. I don't mind Fedora being different. But if we diverge from
conventions it would be great to have a *good* reason. 

> > Packagers should determine whether
> > they're using APIs that require X and either Requires: java-x11 or Requires:
> > java-headless based on what they really need.  We can then audit the
> > packageset at a later date to determine which packages haven't adjusted
> > their Requirements yet

So what is stopping us from auditing the package set with current non-x11
proposal? There will be bugzillas, it will be easy to see which packages were
automatically converted to headless, which were supposedly fixed by their
maintainers and then just go through them. And at any later point in time
"repoquery --whatrequires java" will give you a list of packages that need to be
audited if they can be migrated to headless.

> agreed, but with the meta-package nobody is forced to change anything
> while any maintainer at any time can say "hey, we do not need the
> graphical components and so we relax now the dependencies"
>
> so anybody can point at any time to whatever package and ask for
> relax the deps to java-headless and at no point in time any change
> is forced since the expierience shows changes can't be forced inside
> Fedora - look how long it took to get native systemd-units and there
> are still packages with sysv-init-scripts

As stated above, metapackage introduces more issues and doesn't solve any.
You can't migrate your package to headless in isolation. You have to migrate
*all* dependencies for it to have any noticeable effect.

What *could* be done is add additional provides "java-x11" to main OpenJDK
package and then have packagers explicitly change to either headless or x11
version. I am not entirely sure what we'd achieve with this though (besides
making sure someone has looked at the spec and modified it). If we migrate all
packages to either java-x11 or java-headless those RPMs lose compatibility with
older Fedoras, RHELs etc. Inevitably %if macros will be creeping in and...what
for? So that we can say: "Yes, we have looked at the spec file". 

Last by not least there would be necessary additions of conditionals into
packaging guidelines.

Can we actually list good reasons to have a metapackage or x11 subpackage that
would outweight the inevitable disadvantages? If you *really* feel I
misunderstood these two ideas we can start an etherpad or something so we can
ping-pong more effectively on specific issues.


-- 
Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux