From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11831 invoked by alias); 4 Mar 2002 21:25:08 -0000 Mailing-List: contact rhug-rhats-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: rhug-rhats-owner@sources.redhat.com Received: (qmail 11777 invoked from network); 4 Mar 2002 21:25:06 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 4 Mar 2002 21:25:06 -0000 Received: from dhcppc2 (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA01964; Mon, 4 Mar 2002 13:25:01 -0800 (PST) Subject: Re: RPM notes From: Anthony Green To: tromey@redhat.com Cc: rhug-rhats@sources.redhat.com In-Reply-To: <87zo1odnu9.fsf@creche.redhat.com> References: <1015143611.1759.90.camel@dhcppc2> <87zo1odnu9.fsf@creche.redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 (1.0.2-0.7x) Date: Mon, 04 Mar 2002 13:25:00 -0000 Message-Id: <1015277134.1647.123.camel@dhcppc2> Mime-Version: 1.0 X-SW-Source: 2002-03/txt/msg00006.txt.bz2 On Mon, 2002-03-04 at 13:28, Tom Tromey wrote: > I think it would make sense to generate all the RPMs for a given > package at once: the ordinary bytecode RPM, plus the corresponding > devel package, plus both rhug packages. I only envision 3 packages: * The native runtime binary package * The noarch package with .jar and property files. * The devel package with static libs, headers and API documentation. What is the fourth? > This might mean coordinating > with the vendors in some way. What do you think of that? The benefit > is version consistency, and also single ownership of the .jar file. In a perfect world, yes... however I suspect that this will be difficult to get going. For instance, the RPMs I've seen for many of these packages are already maintained by 3rd parties. The RPM maintainers would have to be sufficiently motivated to maintain dual build systems (ANT, which is almost the universal build tool of choice for Java, and the rhug mechanism -- or we somehow figure out how to build binaries from ANT (I am skeptical, or we figure out an automated ANT -> autotool converter). We have a number of local hacks to work around (1) compiler bugs and (2) different runtime features and (3) different runtime semantics. These would have to be maintained somehow as well. We can try to push as many upstream as possible. > This is great work, btw. Thanks! I got many more packages cleaned up yesterday. Probably more than half are done now. AG