On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
> >> Given that we already have a tool that can download upstream
> >> sources, with or without mangling, and can be used by facilities
> >> outside of the unpacked Debian source package to determine if there was
> >> new
On Mon, Mar 16, 2009 at 11:38:50AM -0500, Manoj Srivastava wrote:
> I am opposed to bloating the policy with dictum that are
> unnecessary, but I see your point about the API. The API is essentially
> the watch file, and we already specify that in the policy. DEHS (as
> mentioned in pol
On Tue, 17 Mar 2009, Manoj Srivastava wrote:
> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
> > It seems to me that you are indeed close, but with the exception of
> > this required include in all our debian/rules, which will be a PITA to
> > achieve.
>
> Modulo debhelper, cdbs, et.al ca
Raphael Hertzog writes:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>>
>>
On Fri, Mar 13, 2009, Raphael Hertzog wrote:
> I tried to summarize the problem here:
> http://wiki.debian.org/Teams/Dpkg/DebianRules
Because I was seeing "-g -O2 -g -O2 -Wall" in my builds, I changed some
packages to only CFLAGS += -Wall and inherit the "-O0/-O2 -g" from
dpkg-bp. I added a dp
On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> I also included DEB_VENDOR in the set of variables. This variable is not
> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
> to become more used in the future for things like this:
> - enable additional patch/features dependin
Loïc Minier wrote:
> On Wed, Mar 18, 2009, Raphael Hertzog wrote:
>> I also included DEB_VENDOR in the set of variables. This variable is not
>> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
>> to become more used in the future for things like this:
>> - enable additiona
Hi,
sadly this didden happen in 2003-2009, but I'd like this to become a reality
for our next release sometime in 2010 or hopefully not 2011 ;-)
Any takers? (To propose this as a release goal & bringing this into policy.)
Sadly I'm too busy for this, but I thought I'd at least remark it.
rega
On Wed, 18 Mar 2009, Loïc Minier wrote:
> If you implement conditional behavior in your rules, typically based on
> lsb_release -is output:
> if vendor is Ubuntu:
> foo
> elif vendor is Debian:
> bar
> you face a problem when you meet:
> else:
>
> What behavior should one use here?
On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> Of course an Ubuntu derivative could be surprised if they get
> a Debian-variant of a package instead of an Ubuntu-variant…
Yes, that's exactly the issue I'm raising
> I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> describe pa
On Wed, Mar 18, 2009, Emilio Pozuelo Monfort wrote:
> There is a good use case for this that doesn't require a conditional, which is
> passing --with-package-name=$(DEB_VENDOR) to configure for packages that have
> this option (e.g. the GStreamer stack, that right now checks
> lsb_release -si outpu
On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> > if vendor is Ubuntu:
> > foo
> > elif vendor is Debian:
> > bar
> > you face a problem when you meet:
> > else:
> >
> > What behavior should one use here?
>
> Debian should always be the "else" because it's the default case. It
> ensur
On Wed, Mar 18, 2009 at 11:52:27AM +0100, Loïc Minier wrote:
> On Fri, Mar 13, 2009, Raphael Hertzog wrote:
> > I tried to summarize the problem here:
> > http://wiki.debian.org/Teams/Dpkg/DebianRules
>
> Because I was seeing "-g -O2 -g -O2 -Wall" in my builds, I changed some
> packages to only
On Wed, Mar 18 2009, Raphael Hertzog wrote:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > ach
On Wed, Mar 18 2009, Steve Langasek wrote:
> On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
>> >> Given that we already have a tool that can download upstream
>> >> sources, with or without mangling, and can be used by facilities
>> >> outside of the unpacked Debian so
On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> So according to your rule that policy should standardize "common practice"
> and not mandate something completely new, the env variable proposal is in
> more widespread usage.
For ten years, the "common practice" was that dpkg-buil
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable.
>
> We cannot standardize on the "env variable proposal" because such proposal has
> never be made. Instead dpkg-buildpackage was broken in
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more wi
Steve Langasek writes:
> On Wed, Mar 18, 2009 at 12:52:39AM +0100, Rafael Laboissiere wrote:
>> * Bill Allombert [2009-03-17 17:02]:
>
>> > What is the rational for making the library private in the first place ?
>
>> In the case of the octave package, it is a decision of the upstream
>> authors
Hello,
On Wed, 18 Mar 2009, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more widespread usag
Manoj Srivastava writes:
> Also, any upstream Makefile that sets CFLAGS (don't most ones
> that use automake do that?) will also be not affected, unless even more
> hackery is done. At this point, what dpkg does to these variables not
> enough to justify any such effort.
Most packages
Raphael Hertzog writes:
> I can understand you were not happy with the way the change was done but
> saying dpkg-bp is broken is strong (and wrong). If you really believed
> that a major mistake was done at that time, you could have complained
> louder and you could have asked for a tech-ctte rul
Holger Levsen writes:
> sadly this didden happen in 2003-2009, but I'd like this to become a
> reality for our next release sometime in 2010 or hopefully not 2011 ;-)
>
> Any takers? (To propose this as a release goal & bringing this into policy.)
This was one of the things that I was hoping to
Manoj Srivastava schrieb:
> On Mon, Mar 16 2009, Raphael Hertzog wrote:
>
>> On Sun, 15 Mar 2009, Bill Allombert wrote:
>>> There is no documented semantic for CFLAGS et. al. in Debian policy. While
>>> some Makefile handle it in a certain way, this is not mandatory in
>>> any way. For example so
Bill Allombert writes:
> Is there actually packages that does not use debconf ?
I'm not sure how many of these were false positives, but I'm fairly sure
that at least some of them are real:
http://lintian.debian.org/tags/read-in-maintainer-script.html
> Should we draft an exception for the few
Raphael Hertzog schrieb:
> On Wed, 18 Mar 2009, Loïc Minier wrote:
>> If you implement conditional behavior in your rules, typically based on
>> lsb_release -is output:
>> if vendor is Ubuntu:
>> foo
>> elif vendor is Debian:
>> bar
>> you face a problem when you meet:
>> else:
>>
>>
Matthias Klose writes:
> Manoj Srivastava schrieb:
>> A) Provide a way to specify project wide defaults for env variables
>> B) Allow a site admin to selectively override these, and provide site
>> wide defaults
>> C) Allow a package to set some flags that would otherwise break the
>>
On Wed, 18 Mar 2009, Matthias Klose wrote:
> > I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> > describe parent relationship, and create a new tool to query those
> > meta-information) but I wonder what impact you expect it would have
> > on the decision of exporting DEB_VEND
On Wed, Mar 18, 2009 at 01:46:03PM -0700, Russ Allbery wrote:
> Holger Levsen writes:
>
> > sadly this didden happen in 2003-2009, but I'd like this to become a
> > reality for our next release sometime in 2010 or hopefully not 2011 ;-)
> >
> > Any takers? (To propose this as a release goal & bri
Andrew McMillan writes:
> The current relevant text is:
>
> Package maintainer scripts may prompt the user if necessary.
> Prompting should be done by communicating through a program,
> such as debconf, which conforms to the Debian Configuration
> Management Specif
On Wed, 2009-03-18 at 14:42 -0700, Russ Allbery wrote:
>
> I'm not sure how many of these were false positives, but I'm fairly sure
> that at least some of them are real:
>
> http://lintian.debian.org/tags/read-in-maintainer-script.html
Not all that many, and some will be false positives. I thi
On Wed, Mar 18, 2009 at 10:29:35PM +0100, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 01:46:03PM -0700, Russ Allbery wrote:
> > Holger Levsen writes:
> > > sadly this didden happen in 2003-2009, but I'd like this to become a
> > > reality for our next release sometime in 2010 or hopefully not
On Wed, Mar 18, 2009 at 08:26:54PM -0700, Russ Allbery wrote:
> The only other thing that I'm not sure about is what to do about preinst
> scripts. Are we requiring debconf for preinst prompting (and hence
> requiring a Pre-Depends) for non-essential packages?
I think we should be requiring it.
Steve Langasek writes:
> On Wed, Mar 18, 2009 at 08:26:54PM -0700, Russ Allbery wrote:
>> The only other thing that I'm not sure about is what to do about
>> preinst scripts. Are we requiring debconf for preinst prompting (and
>> hence requiring a Pre-Depends) for non-essential packages?
> I th
Manoj Srivastava writes:
> Also, there is the funny case of config scripts; these are run
> even before preinst, and before any pre-dependencies are installed. And
> yet, these scripts are often used to prompt using debconf; they must be
> no-ops if debconf is not yet installed (they g
On Wed, Mar 18 2009, Bill Allombert wrote:
> Is there actually packages that does not use debconf ?
ucf has code to fall back to using prompting to the console if
debconf is not available. Of course, this fails if the installation is
being run from a GUI, with the real tty buried.
On Wed, Mar 18 2009, Russ Allbery wrote:
> The only other thing that I'm not sure about is what to do about preinst
> scripts. Are we requiring debconf for preinst prompting (and hence
> requiring a Pre-Depends) for non-essential packages?
Why should debconf be treated any differently t
On Wed, Mar 18, 2009 at 10:29:35PM +0100, Bill Allombert wrote:
> Is there actually packages that does not use debconf ?
dpkg...
sean
signature.asc
Description: Digital signature
38 matches
Mail list logo
