[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: cdk 1.2.7-1



On Mon, Apr 18, 2011 at 2:49 PM, Egon Willighagen
<egon.willighagen@gmail.com> wrote:
> On Mon, Apr 18, 2011 at 10:26 AM, Onkar Shinde <onkarshinde@gmail.com> wrote:
>> On Mon, Apr 18, 2011 at 12:39 PM, Egon Willighagen
>> <egon.willighagen@gmail.com> wrote:
>>> Can you please file patch 21 and 22 'upstream'? Preferably as Git
>>> patches, but the raw Debian patches are fine with me too:
>>>
>>> http://sourceforge.net/tracker/?group_id=20024&atid=320024
>>>
>>> If non-git patches, is the name and email you sent this message with
>>> OK for me to use as 'author' info, when I apply the patches? (Though I
>>> will need to check them first...)
>>
>> All changes in these patches may not be applicable to upstream. I will
>> check which ones are applicable and send patches accordingly.
>
> That I can decide on when you uploaded them... Some patches may be
> done differently... e.g. for Debian I had set up a scheme that takes
> care of different jar names, which would make the patch much
> smaller...
>
> What I am rather trying to say, is that the patch indicates a
> deficiency in the build system, and I am eager to make the build
> system is good as possible, so that your work involves as minimal as
> patching as possible...
>
> The vecmath patch is an interesting example, and could simply be
> solved upstream by renaming the jar according to Debian guidelines.
> The same for log4j and xom, but I note that with log4j you are
> actually *adding* the version number, rather than removing it.

When java libraries are packaged in Debian the jar files are named
<libraryname>-<version>.jar and there is a symlink present with name
<libraryname>.jar. The reason that I replaced all the versioned name
in various dependencies with version less name is that the version
used by cdk may not be matching with Debian version. Log4j is special
case that it's jar names do not comply with this policies.
We do not expect upstream developers to change their build system to
cope with Debian policies.
As of now the only suggestion I can give is to improve build system is
to not use specific jar names in build dependencies but load all jar
files form a directory.
ex.
<fileset dir="${lib.dir}">
  <include name="*.jar"
</fileset>
This way the lib.dir can be overriden using ant arguments when
building package in Debian.

Anyway let me know which branch to use to generate git patches and I
will send them. Trunk or any 1.2.x specific branch?

Cheers,
Onkar
-- 
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.


Reply to: