> Ah, wouldn't that be nice. If every package maintained compatibility > release to release, we could do that. But that doesn't always happen. > For example, Kawa's package hierarchy is going through some > reorganization, such that if I compile BRL against Kawa 1.6.67 won't > work with Kawa 1.6.70 (solved just by recompiling). Isn't that what the Debian package "conflicts" and "requires" settings are for? If I compile Apache against libc5 and then replace libc5 with libc6, Apache's going to break until I recompile, right? However, the Debian packaging system safely navigated us through that migration... so I don't see why it wouldn't work here. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
- Re: packaging jars vs. classes Aaron Brashears
- Re: packaging jars vs. classes Matt Zimmerman
- Re: packaging jars vs. classes Stephane Bortzmeyer
- Re: packaging jars vs. classes per
- Re: packaging jars vs. classes Juergen Kreileder
- Re: packaging jars vs. classes Joe Emenaker
- Re: packaging jars vs. classes Aaron Brashears
- Re: packaging jars vs. classes Cris J. Holdorph
- Re: packaging jars vs. classes per
- Re: packaging jars vs. classes Juergen Kreileder
- Re: packaging jars vs. classes Joe Emenaker
- Re: packaging jars vs. classes Seth Arnold
- Re: packaging jars vs. classes Joe Emenaker
- Re: packaging jars vs. classes Nic Ferrier
- Re: packaging jars vs. classes Joe Emenaker
- Re: packaging jars vs. classes Nic Ferrier
- Java Web Start Christopher Cobb
- Re: packaging jars vs. classes Aaron Brashears
- Re: packaging jars vs. classes Nic Ferrier
- Re: packaging jars vs. classes Nicolás Lichtmaier
- Re: packaging jars vs. classes Stephane Bortzmeyer