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. I think that one of the reasons
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. I think that one of the rea
Rafael Laboissiere writes:
> * 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. I think that one of the reasons is to avoid name clashes
> between diffe
* 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. I think that one of the reasons is to avoid name clashes between
different branches of octave. For instanc
On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
> On Tue, Mar 17, 2009 at 11:36:07AM -0500, Manoj Srivastava wrote:
>> # in debian/rules
>> -include /etc/buildpackage.mk
>
> It seems to me that you are indeed close, but with the exception of
> this required include in all our debian/rules, which w
On Tue, Mar 17, 2009 at 11:36:07AM -0500, Manoj Srivastava wrote:
> # in debian/rules
> -include /etc/buildpackage.mk
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. AFAIU Raphael's proposal, the s
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> And you are missing the point that making people type stuff on
>> the command line for site specific stuff looses out to being able to
>> edit a conffile instead.
>
> Who said the command line
On Tue, Mar 17 2009, Raphael Hertzog wrote:
> What are the pros mentioned by Manoj that are specific to the Makefile
> snippet approach except the fact that we can continue to call debian/rules
> directly on all packages ?
That by itself is reason enough, I think.
Secondly, I ha
On Tue, Mar 17, 2009 at 04:10:27PM +0100, Rafael Laboissiere wrote:
> * Steve Langasek [2009-03-16 07:52]:
>
> > This recommendation needs to be elminated entirely. It is *not* ok for
> > packages that provide libraries to stick extra linker paths in the global
> > configuration, whether by modi
On Mon, Mar 16, 2009 at 03:14:25AM -0500, Manoj Srivastava wrote:
> On Mon, Mar 16 2009, Ben Finney wrote:
>
> > Manoj Srivastava writes:
> >
> >> I would not be against a recommendation in policy to implement
> >> direct-from-vcs upstream tarballs to be created vbia get-orig-source,
>
* Steve Langasek [2009-03-16 07:52]:
> This recommendation needs to be elminated entirely. It is *not* ok for
> packages that provide libraries to stick extra linker paths in the global
> configuration, whether by modifying ld.so.conf or by adding to
> /etc/ld.so.conf.d. Either the libraries pr
Stefano Zacchiroli wrote:
[...]
> NACK. While uscan can be considered an API, it looks much like an
> implementation to me. The API you get with it is that you can call
> "uscan" with its parameters, but you cannot implement that API with
> anything else. An API is something I expect to be able t
On Mon, 2009-03-16 at 07:52 -0700, Steve Langasek wrote:
> This recommendation needs to be elminated entirely. It is *not* ok for
> packages that provide libraries to stick extra linker paths in the global
> configuration, whether by modifying ld.so.conf or by adding to
> /etc/ld.so.conf.d. Eithe
Kurt Roeckx writes:
> On Mon, Mar 16, 2009 at 10:44:49AM -0700, Russ Allbery wrote:
>> Steve Langasek writes:
>>
>> > This recommendation needs to be elminated entirely. It is *not* ok for
>> > packages that provide libraries to stick extra linker paths in the
>> > global configuration, whethe
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.
Of course, nobody would object to that, but this bit can be seen as
necessary.
> The API is essentially the watch file, a
On Mon, 16 Mar 2009, Raphael Geissert wrote:
> Stefano Zacchiroli wrote:
> >
> > ... and pretty please, do not choose a solution that will require
> > adding an "-include" to 15'000 thousands debian/rules; we will finish
> > doing that by Lenny+50, the earliest.
>
> It would take some time, yes;
16 matches
Mail list logo
