FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 03-28-2008, 12:50 PM
Fernando Nasser
 
Default Java packaging guidelines draft

Deepak Bhole wrote:

* 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.




We had agreed on an "exit clause" of dropping this when the RPM/yum
Capabilities (?) feature became available to replace the deprecated
Groups, so we could mark packages with various attributes like "Java",
"JPP" etc, and select them at will in all sorts of operations.


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-28-2008, 03:55 PM
"Tom "spot" Callaway"
 
Default Java packaging guidelines draft

On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
> We had agreed on an "exit clause" of dropping this when the RPM/yum
> Capabilities (?) feature became available to replace the deprecated
> Groups, so we could mark packages with various attributes like
> "Java",
> "JPP" etc, and select them at will in all sorts of operations.

This could just as easily go in the "Group:" tag, and not complicate the
n-v-r.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Fri Mar 28 20:30:01 2008
Return-path: <fedora-list-bounces@redhat.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Fri, 28 Mar 2008 18:56:39 +0200
Received: from hormel1.redhat.com ([209.132.177.33] helo=hormel.redhat.com)
by s2.java-tips.org with esmtp (Exim 4.68)
(envelope-from <fedora-list-bounces@redhat.com>)
id 1JfHsd-0007Pi-Hp
for tom@linux-archive.org; Fri, 28 Mar 2008 18:56:39 +0200
Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110])
by hormel.redhat.com (Postfix) with ESMTP id A3119618573;
Fri, 28 Mar 2008 12:56:18 -0400 (EDT)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id
m2SGuGiK022254 for <fedora-list@listman.util.phx.redhat.com>;
Fri, 28 Mar 2008 12:56:16 -0400
Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2SGuG5n019276
for <fedora-list@redhat.com>; Fri, 28 Mar 2008 12:56:16 -0400
Received: from mars.math-info.univ-paris5.fr (mars.math-info.univ-paris5.fr
[193.48.200.18])
by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m2SGtjpZ000479
for <fedora-list@redhat.com>; Fri, 28 Mar 2008 12:55:46 -0400
Received: from [127.0.0.1] (mars.math-info.univ-paris5.fr [127.0.0.1])
by mars.math-info.univ-paris5.fr (8.14.1/jtpda-5.4) with ESMTP id
m2SGtid1023567
for <fedora-list@redhat.com>; Fri, 28 Mar 2008 17:55:45 +0100
Message-ID: <47ED2310.2020702@math-info.univ-paris5.fr>
Date: Fri, 28 Mar 2008 17:55:44 +0100
From: =?UTF-8?B?RnJhbsOnb2lzIFBhdHRl?=
<francois.patte@math-info.univ-paris5.fr>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: For users of Fedora <fedora-list@redhat.com>
References: <47ECD00A.8060305@math-info.univ-paris5.fr>
<fsipa3$5um$1@ger.gmane.org>
In-Reply-To: <fsipa3$5um$1@ger.gmane.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Miltered: at mars.math-info.univ-paris5.fr with ID 47ED2310.000 by Joe's
j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Score: MSGID : 47ED2310.000 on mars.math-info.univ-paris5.fr :
j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-RedHat-Spam-Score: -0.078
X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254
X-Scanned-By: MIMEDefang 2.63 on 172.16.48.32
X-loop: fedora-list@redhat.com
Subject: Re: compiling emacs 23 on f8
X-BeenThere: fedora-list@redhat.com
X-Mailman-Version: 2.1.5
Precedence: junk
Reply-To: For users of Fedora <fedora-list@redhat.com>
List-Id: For users of Fedora <fedora-list.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-list>,
<mailto:fedora-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/fedora-list>
List-Post: <mailto:fedora-list@redhat.com>
List-Help: <mailto:fedora-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-list>,
<mailto:fedora-list-request@redhat.com?subject=subscribe>
Sender: fedora-list-bounces@redhat.com
Errors-To: fedora-list-bounces@redhat.com
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 28.03.2008 13:45, Neal Becker a =C3=A9crit :
| Fran=C3=A7ois Patte wrote:

|>
|> I try to compile emacs 23 in order to have a multi-scripts emacs with
|> indian scripts.
|>

|>
|
| You can find m17n in development.
| rpm -qa m17*
| m17n-lib-devel-1.5.1-1.fc9.i386
| m17n-lib-devel-1.5.1-1.fc9.x86_64
| m17n-lib-1.5.1-1.fc9.x86_64
| m17n-lib-1.5.1-1.fc9.i386
| m17n-db-1.5.1-1.fc8.noarch
|
| My libotf package is just (hopefully) about to be accepted. You can
find it here:
| http://nbecker.dyndns.org/RPM
|
| You can find my emacs-23.0.60.1 svn srpm as of yesterday there as well.

OK. Thank you. I got the whole stuff to rpmbuild emacs 23 and succeeded.

One remark: the construction:
emacs-->/etc/alternatives/emacs-->/usr/bin/emacs-23.60

is missing .....

Now regarding the Indian scripts, the problem is the same as before. OK,
more languages are added (bengali, tamil,...) but Emacs cannot find
fonts to display these scripts.

I have a lot of Indian fonts on my system, including cdac fonts which
are listed in Options-->Mule-->List Character Sets, but if you ask "show
the character tables", it is empty.....

Or I don't know how to use these new possibilities....

Last: if I enable devanagari-* input method, I get some display of the
glyphs, but it is ugly for the fonts used are unable to build any
ligatures which is a big problem for Indian scripts!! With this
devanagari input method, Emacs 22-1 used cdac fonts which are ligature
capable.

How to automatically enable a font set according to the input method
required? This is done for chinese, japanese...

Thanks for help.

- --
Fran=C3=A7ois Patte
UFR de math=C3=A9matiques et informatique
Universit=C3=A9 Paris Descartes
45, rue des Saints P=C3=A8res
F-75270 Paris Cedex 06
T=C3=A9l. +33 (0)1 44 55 35 61
http://www.math-info.univ-paris5.fr/~patte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH7SMGdE6C2dhV2JURAoI2AJ9rLFXzLSO+PjFxS09sB6 yeM2+4wACgw9Se
gyjxir579gB7QSyyovdTZpM=3D
=3DTcF7
-----END PGP SIGNATURE-----

--=20
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 05:23 PM
Deepak Bhole
 
Default Java packaging guidelines draft

* Tom spot Callaway <tcallawa@redhat.com> [2008-03-28 12:55]:
> On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
> > We had agreed on an "exit clause" of dropping this when the RPM/yum
> > Capabilities (?) feature became available to replace the deprecated
> > Groups, so we could mark packages with various attributes like
> > "Java",
> > "JPP" etc, and select them at will in all sorts of operations.
>
> This could just as easily go in the "Group:" tag, and not complicate the
> n-v-r.
>

No easy to sort with that though. With the release having jpp in there,
one can just do rpm -qa | grep jpp

As for the reason why sort is needed... well, Java is sort of a special
case in that it is the only set that has all packages available from a
different vendor. So if someone wants to replace the Fedora Java stack
with the JPackage Java stack or vice versa, they need to be able to
easily find out the set..

Deepak

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-28-2008, 05:28 PM
Jeremy Katz
 
Default Java packaging guidelines draft

On Fri, 2008-03-28 at 14:23 -0400, Deepak Bhole wrote:
> * Tom spot Callaway <tcallawa@redhat.com> [2008-03-28 12:55]:
> > On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
> > > We had agreed on an "exit clause" of dropping this when the RPM/yum
> > > Capabilities (?) feature became available to replace the deprecated
> > > Groups, so we could mark packages with various attributes like
> > > "Java",
> > > "JPP" etc, and select them at will in all sorts of operations.
> >
> > This could just as easily go in the "Group:" tag, and not complicate the
> > n-v-r.
> >
>
> No easy to sort with that though. With the release having jpp in there,
> one can just do rpm -qa | grep jpp
>
> As for the reason why sort is needed... well, Java is sort of a special
> case in that it is the only set that has all packages available from a
> different vendor. So if someone wants to replace the Fedora Java stack
> with the JPackage Java stack or vice versa, they need to be able to
> easily find out the set..

This is a pretty silly line of reasoning. If people are replacing the
entire stack, then _something_ is being done wrong.

Either we're
a) providing an adequate and effective Java environment (... which is
what I think we're doing) in which case, we don't _want_ our users going
off and replacing things wholesale like you're saying.
b) Or we're not. In which case, we should stop sucking and fix it.

If Java gets a free ride of specialness here, then why not do the same
when someone start GPackage.org (with packages of all your GNOME desktop
bits!) or KPackage.org. But we don't do that. In fact, we've
explicitly worked hard such that the KDE bits in Fedora are good rather
than having people go off and use kde-redhat (hats off to Rex for his
work here)

Jeremy

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-28-2008, 05:36 PM
Fernando Nasser
 
Default Java packaging guidelines draft

Tom "spot" Callaway wrote:

On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum
Capabilities (?) feature became available to replace the deprecated
Groups, so we could mark packages with various attributes like
"Java",
"JPP" etc, and select them at will in all sorts of operations.


This could just as easily go in the "Group:" tag, and not complicate the
n-v-r.



Unfortunately not. We've tried, remember? There were some
bugs/limitations in rpm and yum that prevented us to use it
(don't ask me to remember the details after so long, but it is in the
archives). Over those 3 months we tried _everything_ in existance util
we all concluded that we needed the new tag.


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-28-2008, 05:39 PM
Fernando Nasser
 
Default Java packaging guidelines draft

Deepak Bhole wrote:

* Tom spot Callaway <tcallawa@redhat.com> [2008-03-28 12:55]:


On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:

We had agreed on an "exit clause" of dropping this when the RPM/yum
Capabilities (?) feature became available to replace the deprecated
Groups, so we could mark packages with various attributes like
"Java",
"JPP" etc, and select them at will in all sorts of operations.


This could just as easily go in the "Group:" tag, and not complicate the
n-v-r.




No easy to sort with that though. With the release having jpp in there,
one can just do rpm -qa | grep jpp

As for the reason why sort is needed... well, Java is sort of a special
case in that it is the only set that has all packages available from a
different vendor. So if someone wants to replace the Fedora Java stack
with the JPackage Java stack or vice versa, they need to be able to
easily find out the set..

Deepak

The same happens when we are developing a new stack and on several other
scenarios that were described and examined long ago. The conclusion was
that the new RPM+Yum things was the solution for everything, and that by
that time we would be able to remove that clause.


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-28-2008, 06:18 PM
Deepak Bhole
 
Default Java packaging guidelines draft

* Jeremy Katz <katzj@redhat.com> [2008-03-28 14:29]:
> On Fri, 2008-03-28 at 14:23 -0400, Deepak Bhole wrote:
> > * Tom spot Callaway <tcallawa@redhat.com> [2008-03-28 12:55]:
> > > On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
> > > > We had agreed on an "exit clause" of dropping this when the RPM/yum
> > > > Capabilities (?) feature became available to replace the deprecated
> > > > Groups, so we could mark packages with various attributes like
> > > > "Java",
> > > > "JPP" etc, and select them at will in all sorts of operations.
> > >
> > > This could just as easily go in the "Group:" tag, and not complicate the
> > > n-v-r.
> > >
> >
> > No easy to sort with that though. With the release having jpp in there,
> > one can just do rpm -qa | grep jpp
> >
> > As for the reason why sort is needed... well, Java is sort of a special
> > case in that it is the only set that has all packages available from a
> > different vendor. So if someone wants to replace the Fedora Java stack
> > with the JPackage Java stack or vice versa, they need to be able to
> > easily find out the set..
>
> This is a pretty silly line of reasoning. If people are replacing the
> entire stack, then _something_ is being done wrong.
>
> Either we're
> a) providing an adequate and effective Java environment (... which is
> what I think we're doing) in which case, we don't _want_ our users going
> off and replacing things wholesale like you're saying.
> b) Or we're not. In which case, we should stop sucking and fix it.
>

It is not a matter of sucking as much as a matter of completion. In my
previous mail I stated this: A majority of our Java stack is just
indirect dependencies of Eclipse and Maven. JPackage on the other hand
has a lot more packages, many usable directly by the user.

In an ideal world, users would be able to mix and match packages from
Fedora and JPackage. However, that is not always acceptable to users.
For example, Fedora natively compiles most of the Java packages, has
patches to make things build with gcj (com.sun.* packages for example),
etc. JPackage on the other hard supports only proprietary vm's, so some
packages have different packages and may behave slightly different.

> If Java gets a free ride of specialness here, then why not do the same
> when someone start GPackage.org (with packages of all your GNOME desktop
> bits!) or KPackage.org. But we don't do that. In fact, we've
> explicitly worked hard such that the KDE bits in Fedora are good rather
> than having people go off and use kde-redhat (hats off to Rex for his
> work here)
>

Because neither GPackage nor KPackage exist. JPackage existed before
Fedora did, and it's long existence is the reason it has such a large
set of Java packages. Additionally, Java is far more portable than
C/C++. A GPackage/KPackage could be more pain than they are worth, given
that different distros have different libraries. With Java, that is not
an issue ... that is what has sustained JPackage for so long.

Deepak

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 07:18 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org