Rockbox mail archiveSubject: Re: [RaaA] Weekly status report
Re: [RaaA] Weekly status report
From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Thu, 24 Jun 2010 23:48:54 +0200
On Thu, Jun 24, 2010 at 02:42:36PM +0100, Alex Bennee wrote:
> On 23 June 2010 10:25, Alex Parker <parker.alex.e_at_gmail.com> wrote:
> > On 22 June 2010 18:46, Daniel Stenberg <daniel_at_haxx.se> wrote:
> >> On Tue, 22 Jun 2010, Thomas Martitz wrote:
> >>> For a redistributable .zip (if we want that) we probably could stick to
> >>> the single .rockbox approach, but for compiling from source and for
> >>> distributions/windows installers we want something more application typical
> >>> I think.
> >> IMHO, binary RaaA packages should use "native" packaging and installing
> >> methods. That means .debs and .rpms on Linux and installer-things on
> >> Windows.
> > And .tar.xz (Arch)!
> >.. build from source (or do our own packages for
> > different distros).
> TBH it's probably good enough to support --prefix and maybe the
> ability to specify particular library paths in the configure line.
> Distributions very rarely directly use the packages packaging as there
> is often a bunch of ancillary stuff to comply with the various distro
I have to agree here. It's nice to have packages for lots of distributions,
but I think it's perfectly acceptable to handle those by waiting for
patches from people who use those distributions.
> For Windows it probably does make sense to package things into a
> setup.exe (or whatever it is these days).
Probably, yes, but here again leaving that to someone who's done this
sort of thing before might be a good idea.
If Thomas wants to have fun packaging stuff, I don't mind, but I
personally wouldn't count this as a requirement for the RaaA project.
Making sure the configure script handles everything that's needed to
allow this packaging is of course needed.
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. KernighanReceived on 2010-06-24