|
|

03-27-2008, 07:54 PM
|
|
|
Java packaging guidelines draft
* Tom spot Callaway <tcallawa@redhat.com> [2008-03-27 15:25]:
> On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
> > An important reason we need the jpp in there currently is to maintain
> > compatibility with JPackage.
>
> We have never supported repository mixing. If anything, this serves as a
> good reason that JPackage should drop their disttag.
>
How many other repositories are there with the entire stack duplicated?
(not being sarcastic.. I really don't know of any). I know that there
were conflicts with Livna and what not a while ago, but those were for a
handful of packages only.
As for JPackage dropping their release tag policy -- not to be the devil's
advocate, but they were here before Fedora...
I have heard of numerous requests for technical arguments as to why the
string is needed. But where the technical arguments as to why it should
be removed? From what I have seen so far, reasons for that are pretty
much "Because it looks better, because it a policy, etc."
Cheers,
Deepak
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 07:57 PM
|
|
|
Java packaging guidelines draft
* Rex Dieter <rdieter@math.unl.edu> [2008-03-27 15:37]:
> Deepak Bhole wrote:
>
>> An important reason we need the jpp in there currently is to maintain
>> compatibility with JPackage.
>> With the way the naming is right now, users can enable a JPackage
>> repository beside a Fedora repo, and are guaranteed to get the latest
>> either from Fedora or JPackage,...
> ...
>> e.g package foo is currently at 1.0-1jpp in jpackage and 1.0-1jpp.1 in
>
> Stripping 'jpp' works fine (at least according to my quick-n-dirty use of
> rpmdev-vercmp:
>
> 1.0-1jpp < 1.0-2 < 1.0-2jpp
>
Until Fedora does a 1.0-3 to fix something, with the -3 still being
split from the 1jpp, never having acquired the fixes from 1jpp->2jpp
Cheers,
Deepak
> -- Rex
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 08:09 PM
|
|
|
Java packaging guidelines draft
On 27/03/2008, Deepak Bhole <dbhole@redhat.com> wrote:
> With the way the naming is right now, users can enable a JPackage
> repository beside a Fedora repo, and are guaranteed to get the latest
> either from Fedora or JPackage, whichever is newer. Without the jpp in
> the release tag, this compatibility is broken. And it goes beyond the
> packages themselves -- it also affects dependent packages,
Is that actually true these days? I gave up on trying to use JPackage
and Fedora together a while ago because there were incompatibilities
that neither side seemed to be falling over themselves to fix.
Not that this is an argument for not allowing this again the future,
of course, and possibly it does work again even now.
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 08:26 PM
|
|
|
Java packaging guidelines draft
On Thu, 2008-03-27 at 15:54 -0400, Deepak Bhole wrote:
> * Tom spot Callaway <tcallawa@redhat.com> [2008-03-27 15:25]:
> > On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
> > > An important reason we need the jpp in there currently is to maintain
> > > compatibility with JPackage.
> >
> > We have never supported repository mixing. If anything, this serves as a
> > good reason that JPackage should drop their disttag.
> >
>
> How many other repositories are there with the entire stack duplicated?
> (not being sarcastic.. I really don't know of any). I know that there
> were conflicts with Livna and what not a while ago, but those were for a
> handful of packages only.
>
> As for JPackage dropping their release tag policy -- not to be the devil's
> advocate, but they were here before Fedora...
>
> I have heard of numerous requests for technical arguments as to why the
> string is needed. But where the technical arguments as to why it should
> be removed? From what I have seen so far, reasons for that are pretty
> much "Because it looks better, because it a policy, etc."
It causes rpm ordering to be painful. The Version and Release should be
wholly numeric, whenever they aren't, rpm's ordering gets rather
non-intuitive. We've defined special, strictly controlled cases when it
is ok to have non-numeric characters in the version or release
(especially release), but only when there is a real need.
So, again, where is the real need for tacking jpp on the end of Release?
~spot
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 08:48 PM
|
|
|
Java packaging guidelines draft
* Tom spot Callaway <tcallawa@redhat.com> [2008-03-27 16:26]:
>
> So, again, where is the real need for tacking jpp on the end of Release?
Fernando said he'd write up the reasons from the last time this argument
was had.
Fernando: how are things going? Please post here when you've got a
wiki page to share.
Andrew
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 08:51 PM
|
|
|
Java packaging guidelines draft
* Tom spot Callaway <tcallawa@redhat.com> [2008-03-27 16:26]:
> On Thu, 2008-03-27 at 15:54 -0400, Deepak Bhole wrote:
> > * Tom spot Callaway <tcallawa@redhat.com> [2008-03-27 15:25]:
> > > On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
> > > > An important reason we need the jpp in there currently is to maintain
> > > > compatibility with JPackage.
> > >
> > > We have never supported repository mixing. If anything, this serves as a
> > > good reason that JPackage should drop their disttag.
> > >
> >
> > How many other repositories are there with the entire stack duplicated?
> > (not being sarcastic.. I really don't know of any). I know that there
> > were conflicts with Livna and what not a while ago, but those were for a
> > handful of packages only.
> >
> > As for JPackage dropping their release tag policy -- not to be the devil's
> > advocate, but they were here before Fedora...
> >
> > I have heard of numerous requests for technical arguments as to why the
> > string is needed. But where the technical arguments as to why it should
> > be removed? From what I have seen so far, reasons for that are pretty
> > much "Because it looks better, because it a policy, etc."
>
> It causes rpm ordering to be painful. The Version and Release should be
> wholly numeric, whenever they aren't, rpm's ordering gets rather
> non-intuitive. We've defined special, strictly controlled cases when it
> is ok to have non-numeric characters in the version or release
> (especially release), but only when there is a real need.
>
Okay, thanks for the clarification.
> So, again, where is the real need for tacking jpp on the end of Release?
>
The need is compatibility with JPackage. Our Java stack is simply not
big enough. Most of the Java packages in Fedora have gone in as direct
and indirect dependencies of Eclipse and Maven. In other words, JPackage
still has a large selection of directly usable Java apps.
*IF* we can convince JPackage to drop jpp, all would be fine. If we
cannot -- are we willing to lose compatibility?
Btw, there is also middleground that I haven't seen being discussed:
What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp
becomes foo-1.0-1.1 in Fedora.
This would maintain compatibility, and would give us numeric releases.
The above compromise would cause us to lose the ability to gather a list
of packages in the Java stack/common packages (with JPackage) though.
Deepak
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 09:00 PM
|
|
|
Java packaging guidelines draft
On Thu, 2008-03-27 at 16:51 -0400, Deepak Bhole wrote:
> Btw, there is also middleground that I haven't seen being discussed:
> What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp
> becomes foo-1.0-1.1 in Fedora.
>
> This would maintain compatibility, and would give us numeric releases.
This is actually permitted with the current guidelines.
~spot
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 09:22 PM
|
|
|
Java packaging guidelines draft
On Thu, Mar 27, 2008 at 11:59 AM, Nicolas Mailhot
<nicolas.mailhot@laposte.net> wrote:
>
> Le Jeu 27 mars 2008 15:57, Thomas Fitzsimmons a écrit :
>
> > Ville Skyttä wrote:
>
> > Yes, I've struggled to understand the same decision in the JDK
> > packages.
> > I wonder why the extra level of versioning is required:
> >
> > $ ls -l /usr/lib/jvm/java-1.7.0-icedtea
> > lrwxrwxrwx 1 root root 26 2007-12-11 14:36
> > /usr/lib/jvm/java-1.7.0-icedtea -> java-1.7.0-icedtea-1.7.0.0
> >
> > Nicolas, do you know the rationale? To enable parallel-installation
> > of multiple versions of the same JDK, perhaps?
>
> When you are in closed JVM hell you need to manage black-boxes and for
> this reason switching between different JVMs (or different builds of
> the same JVM) is very common (talking from an ISV perspective which
> was my job when I wrote the guidelines). You can't trust the vendor to
> fix its bugs timely. You can't trust it not to create regressions in a
> new build (that will take forever to ve fixed). All you can do it get
> a range of jvms and switch between them till you identify the most
> solid.
>
> When openjdk gets solid enough people trust the OS jvm, and when java
> projects get the clue they need to work with any JVM not just the
> particular build they copied in their private build system, I expect
> those possibilities to gradually fall into disuse. But right now easy
> JVM switching is a must for users.
Another reason for parallel JVM installation is when you're working on
different releases of a product that requires different JVM levels.
For instance,
I might have one that is certified to use 1.4.2 and another that requires 1.6.0.
I might be able to run my 1.4.2 under 1.6.0 but that's not always feasible.
jesus rodriguez
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 10:02 PM
|
|
|
Java packaging guidelines draft
On Thu, 2008-03-27 at 17:00 -0400, Tom "spot" Callaway wrote:
> > Btw, there is also middleground that I haven't seen being discussed:
> > What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp
> > becomes foo-1.0-1.1 in Fedora.
> >
> > This would maintain compatibility, and would give us numeric
> releases.
>
> This is actually permitted with the current guidelines.
Not only that, but it was one of the suggested methods to rid ourselves
of jpp. I do believe I had a complete working scheme using just numbers
that left Jpackage with the ability to have "rpm newer" packages than
those in Fedora.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|

03-27-2008, 10:59 PM
|
|
|
Java packaging guidelines draft
* Mary Ellen Foster <foster@in.tum.de> [2008-03-27 16:10]:
> On 27/03/2008, Deepak Bhole <dbhole@redhat.com> wrote:
> > With the way the naming is right now, users can enable a JPackage
> > repository beside a Fedora repo, and are guaranteed to get the latest
> > either from Fedora or JPackage, whichever is newer. Without the jpp in
> > the release tag, this compatibility is broken. And it goes beyond the
> > packages themselves -- it also affects dependent packages,
>
> Is that actually true these days? I gave up on trying to use JPackage
> and Fedora together a while ago because there were incompatibilities
> that neither side seemed to be falling over themselves to fix.
>
> Not that this is an argument for not allowing this again the future,
> of course, and possibly it does work again even now.
>
There have been a few bumps along the way, yes  However, it is our
(Java Team's) intention to always allow smooth interoperability. We
plan to have meeting with JPackage folks in the near term to iron out
the current outstanding issues.
Deepak
> MEF
>
> --
> Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
> Informatik 6: Robotics and Embedded Systems, Technische Universität München
> and ICCS, School of Informatics, University of Edinburgh
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
|
|
|
All times are GMT. The time now is 08:02 AM.
VBulletin, Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org
|