Page 1 of 1

BUG: Info-Oolite.plist should be in the Oolite not -data

Posted: Thu May 04, 2006 3:33 pm
by eddyp
Hello all,

While packaging Oolite for Debian I found that the file Info-Oolite.plist was missing from the Oolite package. The application (IIRC) refused to compile without this file, so I took it by hand from the -data package and placed it in the binary package.

I know that, actually the file in question is mere data, but it seems logical (IMHO) to have that file in the oolite tarball since it is needed during the compilation.

Thus I ask for it to be placed in the oolite binary packge.

Also, in order to have the package compiled properly, I had to create a cuple of directories in the root (Contents and Resources).

Here are the rules that fix the issues for the Debian package.

Code: Select all

patch:
        mkdir -p Contents Resources
        cp debian/patches/Info-Oolite.plist Resources/

unpatch: 
        set -e ; if [ -e Resources/Info-Oolite.plist ]; then \
        rm Resources/Info-Oolite.plist ; \
        fi
        set -e ; if [ -d Resources ]; then \
        rmdir Resources ; \
        fi
        set -e ; if [ -d Contents ]; then \
        rmdir Contents ; \
        fi
IMHO, this kind of things should not happen, so I propose to make these changes.

Probably it would be better to have these directories created "out of the box" so that the package is cleaner.


Please excuse my ignorance if I missed something and this is actualy not a problem.

Posted: Fri May 05, 2006 10:39 am
by winston
This changes post 1.52 because the program changes from a GNUstep app build style to an Objective-C program build style (and jetissons AppKit at the same time). But there are a few fixes I need to back port into 1.52 so this may be one.

Posted: Fri May 05, 2006 5:35 pm
by eddyp
winston wrote:
This changes post 1.52 because the program changes from a GNUstep app build style to an Objective-C program build style (and jetissons AppKit at the same time). But there are a few fixes I need to back port into 1.52 so this may be one.
I am not sure what you ment, but backporting changes to 1.52 makes no sense to me. Is that a supported previous stable release? Was this used as a starting point for some branch which became current trunk while 1.62 was left behind as dead branch?

Or do you mean that you wish to revert lost changes in post 1.52 releases?

Posted: Sat May 06, 2006 7:26 pm
by winston
There are essentially 3 different Linux releases, which represent 3 phases of development. It's not unlike the 3 different Debian releases (Stable, Testing and Unstable).

We have:
Stable - this is 1.52. Occasionally, I'll backport functionality-impacting bug fixes. That's why it's 1.52-5 at the moment - the current 1.52 is the 5th release.
Development - Every so often, I put out a development release. This has had some testing and should work OK.
Nightly - This hasn't been tested at all - it's just what vexed3.alioth.net extracted at 04:00 UTC from SVN and built. It usually runs, but it's got the latest bleeding edge stuff in it so there's a greater chance of it being unstable compared to 'development'.

I'm assuming you're doing things with 1.52-5 for Debian packaging. (On the other hand, if Giles is thinking of releasing 1.55 soon, it might not be worth backporting anything new into 1.52).

Posted: Sun May 07, 2006 1:50 am
by eddyp
Surely you mean 1.62, not 1.52.

Now you can understand my confusion. ;-)

Posted: Sun May 07, 2006 6:00 pm
by winston
Gah. My mind...it's going, I can feel it!

Posted: Sun May 07, 2006 6:58 pm
by Rxke
daisy... daisy....