Hello!
Debian Policy 4.9 says about debian/rules:
"It must start with the line #!/usr/bin/make -f, so that it can be
invoked by saying its name rather than invoking make explicitly."
In the VDR and VDR plugin packages, we use something like this:
/bin/sh debian/make-special-vdr.sh
make-spec
Julien Cristau schrieb:
asks for a password.
Sorry, wrong link:
http://svn.debian.org/wsvn/pkg-vdr-dvb/vdr/vdr/trunk/debian/make-special-vdr.sh
> also nothing in what you said explains why you
can't do what you want using a makefile.
Because make-special-vdr.sh needs to modify debian/rul
Fabian Greffrath wrote:
> Why not so it the other way round, i.e. start two different scripts (or
> the same script with different parameters) from a debian/rules Makefile
> depending on the environment variable?
Might be possible, but it would require major changes to debian/rules, but
our goal
Manoj Srivastava wrote:
> This is what the make directive 'include' is all
> about. Conditionally, include fileA or fileB. Each file is all
> uncontaminated now.
>
> This is not a technical shortcoming of using Makefiles.
You're right. What we do might be possible from "within
Michael Tautschnig wrote:
> Adhering to a standard actually decreases complexity. What may seem "elegant"
> at
> first makes it a lot harder for other people to step in. For example, the
> VDR-solution IMHO doesn't decrease complexity, it merely hides it.
Yes, it indeed hides some complexity. Bu
Michael Tautschnig schrieb:
In an earlier post you mentioned a pbuilder build process: If that is what you
are using, why not go for pbuilder hooks?
This would surely be possible, but then the users compiling their own
packages will complain :-)
@all:
Thanks for your technical suggestions! T
Philipp Kern wrote:
> I didn't say that, right? Please don't lay words into my mouth. I said
> "here" to specify the concrete case of policy describing the first n bytes
> of debian/rules despite the interface being completely in accordance with
> the normal procedures (i.e. being a Makefile and
Manoj Srivastava wrote:
> If I ahve the magic variables set, and call it as
> % make -f ./debian/rules,
> I get the standard behaviour. If I turn around and call it as
> % ./debian/rules,
> I get totally different behaviour.
True but if you DON'T set the magic variable, you g
Kalle Kivimaa wrote:
> the special cases are needed? debian/rules is a specific interface for
> Debian building, why are you using that same interface for other
> purposes?
It's just because we believe this is the easiest to use and easiest to
maintain way to do this:
Build a standard vdr-plugin
Michael Tautschnig schrieb:
I think Manoj already explained quite well why policy is that specific about a
single line.
And I explaind why the policy is over specific in this case :-)
The modified shebang line didn't had any drawback in the past and
wouldn't have any drawback in the future.
Manoj Srivastava schrieb:
1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build
2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build
3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build
4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build
Giving you differing results is confusing enough to anyo
Vincent Bernat wrote:
> Here is the list of package that name the user with the name of the
> source package:
- vdr:vdr
Tobias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Let me express my appreciation and gratitude for Debian.
Reading debian-devel during the last weeks, I had the same feeling that
some positive counterpart to the recent discussions is needed to somehow
keep the "balance". I intended to post the top 5 reasons, why I love
Debian, but you were fast
Grammostola Rosea wrote:
> How should I do it? I've seen a lot of different tools/ways on the
> web... please give me some clear information and good references.
Check out cowbuilder. The follwing references should get you going:
http://wiki.debian.org/cowbuilder
https://wiki.ubuntu.com/Cowdance
Am 11.05.2010 10:41, schrieb Cleto Martin Angelina:
The bug #539568 is an ITP for a C++ sockets library. The ITP was
created on Augus'09. I'm interested in this package too, and I wrote
an email to the bug author and I've received that his email does not
exists. In this cases, what should be do
15 matches
Mail list logo
