On Thu, Apr 21, 2011 at 05:37:14PM +0100, Justin B Rye wrote:
> > You can do packaging without make.
I shoudl have said, without extensive knowledge of make and without
creating Makefile.
> You can't do policy-compliant Debian packaging without make. Policy
> 4.9 says the rules file *must* be an executable makefile; to create
> targets in the rules file I need to speak make-ese.
For all the trivial package, just create debian/rules always as
%:
dh $@
http://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules
> It may be true
> that I'd only be creating a trivial, degenerate make system; but if
> you don't already understand make, using it to automate a build that
> doesn't *need* make is a frustrating task!
Actually, that is only when you do fancy packaging.
I started chap 1&2 updates. I will think the following later in this week.
> >> Now, filling in this missing step would take a lot of work by somebody
> >> other than me, so as a stopgap I'll suggest the alternative of clearly
> >> signposting the hole. Section 2.1 warns against picking a library,
> >> daemon, or setuid program, and insists on executables being in binary
> >> form; at present this looks like an oversight, but instead it could
> >> explicitly advise against interpreted languages. I'm not sure what
> >> justification it could offer for this, though.
> >
> > * command line binary executable using existing libraries.
> > * interpreter based program.
> >
> > These are easier than libraries or daemons. This guide line is common
> > sense thing.
>
> Yes, helloworld.sh is simpler than helloworld.cc; but at present the
> guidelines imply that you should avoid scripting languages because
> they're complex:
Whare did I say avoid "scripting languages"? I need to fix it. I am
recommending shell program as the first trivial packaging practice.
> # * The program should be in binary executable form; libraries are
> # harder to handle.
>
> The "binary" there is conflating two pieces of advice that have
> different rationales. Maybe they should be fractionated out into
> something like:
>
> * The software should be in the form of an executable; libraries are
> harder to handle.
POSIX Shell is better initial try.
Graphics or DOC are easy too.
Popular interpreter languages such as Perl and Python may be as easy as
C. They all need to follow special polity of them though.
> * It should use a common compiled language and build system, since
> this guide can't cover every obscure corner case.
>
> >> Moving on... section 2.3 is "Free portable programs". I don't
> >> understand this title (why isn't it something like "widely used build
> >> systems"?),
> >
> > I can retitle as "Popular free protable build system".
>
> Make that "Popular portable build systems"; "free" is redundant. It
> also seems to require me to read it as "(portable build) systems"
> rather than "portable (build systems)", which is odd, but at least
> it's shorter than any other way of saying it that I can think of.
OK, thanks
Anyway, good night.
Osamu