Any progress?
Don't forget dh_link
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello,
On trečiadienis 16 Kovas 2011 00:06:50 Joey Hess wrote:
Steve Langasek wrote:
This appears to have been the result of a grave misunderstanding on my
part. From the bug log, I mistakenly believed that the only outstanding
question
I apoogize for my poor communication.
(But not
I've searched the lintian lab for debhelper config files
containing ${ -- found none.
Now, when designing an interface like this, I like to try to think a
little bit ahead. Will arbitrary environment variables being expanded
in these files be abused? Will it make packages that are harder
for
On Tue, Mar 15, 2011 at 03:28:12PM -0400, Joey Hess wrote:
I have a new policy: Once Ubuntu applies a patch to software I wrote,
without allowing me to sign off on it[1],
This appears to have been the result of a grave misunderstanding on my part.
From the bug log, I mistakenly believed that
Steve Langasek wrote:
This appears to have been the result of a grave misunderstanding on my part.
From the bug log, I mistakenly believed that the only outstanding question
I apoogize for my poor communication.
(But not for being an asshole; that's really the only option Ubuntu has
left me
Steve Langasek wrote:
As long as you're considering adding this at a new debhelper compat level, I
think we should look at the possibility of v9 being multiarch-by-default -
i.e., passing a multiarch default --libdir (or equivalent) to the build
system with dh_auto_configure, adding
+++ Joey Hess [2011-03-01 11:49 -0400]:
It does seem to me that it would be better to get basic support into
debhelper generally w/o a v9. The kind of assurance I'm looking
for is along the lines of scanning all debhelper config files in Debian
to make sure none contain the new syntax somehow.
I don't feel that looking at the Contents file is good enough. Consider
that some package might sed the files to expand ${..} on its own, somehow.
I haven't tested the entire set of postinst scripts - this could be
done, possibly on lintian.debian.org or similar.
debhelper should not modify
On Tue, Mar 01, 2011 at 12:32:18PM -0400, Joey Hess wrote:
I don't feel that looking at the Contents file is good enough. Consider
that some package might sed the files to expand ${..} on its own, somehow.
How would such a file ever be seen as input by debhelper either?
But unless there are
As long as you're considering adding this at a new debhelper compat level, I
think we should look at the possibility of v9 being multiarch-by-default -
i.e., passing a multiarch default --libdir (or equivalent) to the build
system with dh_auto_configure, adding multiarch-support to ${misc:Depends}
Wookey wrote:
--- Debian/Debhelper/Dh_Lib.pm(revision 7813)
+++ Debian/Debhelper/Dh_Lib.pm(working copy)
@@ -617,6 +617,10 @@
next if /^#/ || /^$/;
}
my @line;
+ # Only expand ${...} environment vars in v8
+
Package: debhelper
Version: 8.1.2
Multiarch support is (finally!) coming along nicely in both Ubuntu and
Debian. (see https://launchpad.net/~vorlon/+archive/multiarch )
I'm not sure how closely you've been following the multiarch work, but
it provides the ability to cleanly install libraries of
12 matches
Mail list logo
