Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit :
The interface definition behind this is:
That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates
it is not the interface.
[...]
For the sake of completeness: Policy states that
Tobi listacco...@e-tobi.net writes:
/usr/share/vdr-dev/dependencies.sh. But the shebang simply is nothing to
worry about.
May I ask what's the reason you're using this kind of a convoluted
system? Wouldn't it be simpler to separate debian/make-special-vdr.sh
and debian/rules, and call
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-*
[...]
Build a development version of the vdr-plugin-* package from the same
source, but using the API of the development version of VDR and with a
different binary package name:
SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot
This way it works out-of-the-box with all
* Tobi listacco...@e-tobi.net [091030 10:55]:
From our point of view this is so easy to do and so easy to maintain (it's
working quite well for over 2 years now), that this very specific
requirement of the policy just seems to be a useless piece of bureaucratic
over-specificiation.
That is
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.
Build a standard vdr-plugin-* package:
dpkg-buildpackage -tc -uc -us -rfakeroot
Build a development version of the vdr-plugin-* package from the same
source, but using the API of the development version of VDR and with a
different binary package name:
SPECIAL_VDR_SUFFIX=devel
On Fri, Oct 30 2009, Tobi wrote:
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 :-)
No. You opined that the policy is over specific, but with
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
On Fri, Oct 30 2009, Tobi wrote:
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
[ I haven't looked the vdr-* source; apologies if I miss something
essential. ]
Tobi wrote:
Personally I think debian/rules shouldn't be restriked to make.
What happens if you do `./debian/rules -p | less'? Although seldom
needed, that's a useful thing when you have to debug the build
Manoj Srivastava sriva...@debian.org writes:
I think it would be a good idea to _add_ to policy a rule that
says that make -f debian/rules and ./debian/rules must behave
identically, to prevent confusion, and to promote reproducibility, and
conform to the principle of least
Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit :
The interface definition behind this is:
That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates
it is not the interface.
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email
Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
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.
Dear all,
I also do not understand that rule.
Am Mittwoch, den 28.10.2009, 19:05 -0500 schrieb Manoj Srivastava:
The solution we have right now is in some way elegant, because you have
only to deal with a standard debian/rules and besides the different
shebang line there's nothing else to care about.
Actually, there is. My
On 28/10/09 at 19:05 -0500, Manoj Srivastava wrote:
Actually, there is. My states makefile can no longer
include debian/rules, because, you see, it is not a makefile. There are
other ways that it does not look like a makefile, walk like a makefile,
or quack like one.
The debian/rules
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. But it
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.
Tobi listacco...@e-tobi.net writes:
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
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!
Le Thu, Oct 29, 2009 at 08:02:46AM +0100, Michael Tautschnig a écrit :
Debian Policy 4.9 guarantees that the behavior of debian/rules will be the
same
if called as either make -f debian/rules or simply debian/rules.
Is there any piece of our infrastructure that needs this feature ? If not,
On Thu, 2009-10-29 at 21:35 +0900, Charles Plessy wrote:
(The source packages needed the format 3.0 (quilt),
for which good news are expected soon.)
Already: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457345
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
Are there any serious objections against just overriding and ignoring
the Linitan warning about not having make -f in the shebang line?
As long as you don't have an objection against having serious bugs filed
and your packages not be part of
On Thu Oct 29 15:58, Michael Banck wrote:
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
Are there any serious objections against just overriding and ignoring
the Linitan warning about not having make -f in the shebang line?
As long as you don't have an objection against having
Are there any serious objections against just overriding and ignoring
the Linitan warning about not having make -f in the shebang line?
It is not an overridable error, and I haven't seen any reason yet to
convince me to make it one. You do have some reasons, but none I have
seen that would not
On 2009-10-29, Joerg Jaspert jo...@debian.org wrote:
It is not an overridable error, and I haven't seen any reason yet to
convince me to make it one. You do have some reasons, but none I have
seen that would not be simple to do in make directly as well.
As long as you have those packages
On Thu, Oct 29 2009, Philipp Kern wrote:
On 2009-10-29, Joerg Jaspert jo...@debian.org wrote:
It is not an overridable error, and I haven't seen any reason yet to
convince me to make it one. You do have some reasons, but none I have
seen that would not be simple to do in make directly as
On 2009-10-29, Manoj Srivastava sriva...@debian.org wrote:
On Thu, Oct 29 2009, Philipp Kern wrote:
On 2009-10-29, Joerg Jaspert jo...@debian.org wrote:
It is not an overridable error, and I haven't seen any reason yet to
convince me to make it one. You do have some reasons, but none I have
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 even
On Thu, Oct 29 2009, Tobi wrote:
But like Philipp, Lucas or Charles I believe, that the policy is too
specific in requiring a fixed shebang line, instead of just stating, that
debian/rules must be a Makefile which should execute itself when ran as a
binary.
What no one has addressed
On Thu, 2009-10-29 at 15:54 +, Matthew Johnson wrote:
On Thu Oct 29 15:58, Michael Banck wrote:
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
Are there any serious objections against just overriding and ignoring
the Linitan warning about not having make -f in the shebang line?
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 get
On Thu, Oct 29, 2009 at 03:54:23PM +, Matthew Johnson wrote:
On Thu Oct 29 15:58, Michael Banck wrote:
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
Are there any serious objections against just overriding and ignoring
the Linitan warning about not having make -f in the
On Thu, 2009-10-29 at 17:58 -0700, Steve Langasek wrote:
Not true. If you were not familiar with the special script, you
would
have to read that entire script to understand what it does. OTOH, in
the
make-only approach it is easier to discard the contents of
alternate-debian-rules.mk
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
On Wed, 2009-10-28 at 16:02 +0100, Tobi wrote:
[1]:
http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh
asks for a password. also nothing in what you said explains why you
can't do what you want using a makefile.
Cheers,
Julien
--
To UNSUBSCRIBE, email to
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
On Wed, Oct 28 2009, Tobi wrote:
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
On Wed, Oct 28 2009, Tobi wrote:
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
Because make-special-vdr.sh needs to modify debian/rules itself.
This way debian/rules doesn't get contaminated with stuff that
goes beyond the scope of building the regular Debian package -e
except for the shebang line.
Why not so it the other way round, i.e. start two different scripts
(or
Tobi wrote:
Or should we just add a Linitan override? Or do we really need to use
#!/usr/bin/make -f as the shebang line in debian/rules?
Use make. it is able to do all the things you're doing right now, including to
do different stuff based on an environment setting.
Personally I would vote
Personally I would vote for dropping the make requirement from the
policy all together. I might be mistaken, but I think none of the
build tools calls make explicitly with debian/rules. A debian/rules
might even be a Python or Rake script.
[Bernd Zeimetz]
Oh god, no. And I'm not even
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 is
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 the
Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
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.
Dear all,
I also do not understand that rule. There are a
On Wed, Oct 28 2009, Tobi wrote:
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
On Wed, Oct 28 2009, Tobi wrote:
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
On Wed, Oct 28, 2009 at 07:05:30PM -0500, Manoj Srivastava wrote:
On Wed, Oct 28 2009, Tobi wrote:
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
48 matches
Mail list logo
