On Sun, Aug 02, 2009 at 10:45:27PM +0200, Torsten Werner wrote:
> Hi,
>
> we still have that package in Debian. Do we really need it?
The following package Build-Depend on it.
libservlet2.3-java
Package: bsh
Package: jcifs
Package: jspwiki
Package: libcommons-fileupload-java
Package: l
Hi,
we still have that package in Debian. Do we really need it?
Cheers,
Torsten
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello,
sorry for joining the discussion late...
On Sun, Aug 02, 2009 at 08:42:14PM +0100, Matthew Johnson wrote:
> In which case, there's no reason to have the symlink, since the jar
> itself will have the API version (and not package version). This gives
> us another option then:
>
> Coinstal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
>> By this you mean we build-depend on a virtual package like libfoo-dev,
>> which is Provided by libfoo0-dev, libfoo1-dev and so on?
> Well, there's two ways of doing this in C libraries. Some provide
> versionned -dev packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ludovic Claude wrote:
> I have recently packaged the clirr tool which does exactly that: give it
> 2 versions of a jar, and it will report any API breaking changes.
Nice, looks useful, but note that it only detects visible API changes, not
more subtl
On Sun Aug 02 20:39, Marcus Better wrote:
> > Separate -dev packages
> > --
> >
> > The heavy-weight approach that is most like C and relies on the package
> > manager a lot.
> >
> > + build-depends don't change between versions
>
> By this you mean we build-depend on a virt
On Sun Aug 02 20:00, Torsten Werner wrote:
> > "upstream release version". API version changes when upstream change the
> > API and is encoded in the package name.
>
> How do I find out if the API has changed in a new upstream version?
As others have said: read the changelog, test it, look at the
I have recently packaged the clirr tool which does exactly that: give it
2 versions of a jar, and it will report any API breaking changes.
Ludovic
Marcus Better a écrit :
> Torsten Werner wrote:
>> How do I find out if the API has changed in a new upstream version?
>
> Well, that is never easy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Torsten Werner wrote:
> How do I find out if the API has changed in a new upstream version?
Well, that is never easy, also not with C libraries if upstream is clueless.
If you are lucky, upstream is responsible enough to document it. Otherwise
it ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
> Separate -dev packages
> --
>
> The heavy-weight approach that is most like C and relies on the package
> manager a lot.
>
> + build-depends don't change between versions
By this you mean we build-depend
Hi Matthew,
thank you for your ideas but I still see a problem.
On Sun, Aug 2, 2009 at 5:53 PM, Matthew Johnson wrote:
> In the list below when I say "version" I mean "API version" not
> "upstream release version". API version changes when upstream change the
> API and is encoded in the package
In my previous mail I talked about some ideas to ease transitions. I've
thought over this a bit more and come up with several different
approaches which could be used. Here is a list with their pros (+) and
cons (-). Bear in mind that in all cases most of the work will be done
for you by javahelpe
12 matches
Mail list logo
