On Thu, Mar 08, 2012 at 07:52:11AM +0100, Reinhard Tartler wrote:
> On Wed, Mar 7, 2012 at 2:32 PM, Michael Hanke wrote:
> > On Wed, Mar 07, 2012 at 12:52:53PM +0100, Andreas Tille wrote:
> >> Was you aware about dpkg-vendor at the time of writing this script?
> >
> > Yes, but AFAIK it was neither
On Wed, Mar 7, 2012 at 2:32 PM, Michael Hanke wrote:
> On Wed, Mar 07, 2012 at 12:52:53PM +0100, Andreas Tille wrote:
>> On Wed, Mar 07, 2012 at 11:17:44AM +0100, Michael Hanke wrote:
>> >
>> > Not exactly the same thing, but for backporting for various releases we
>> > (NeuroDebian) quite often h
On 03/07/2012 05:34 PM, Neil Williams wrote:
> Not within Debian uploads and buildd's, true, but there are good reasons
> for this to remain technically possible for derivatives. The ability for
> someone downstream of Debian to patch debian/control[.in]
Our policy doesn't apply to derivatives (th
On 03/07/2012 07:15 PM, Bernhard R. Link wrote:
> Whether it might make sense for derivatives to mangle upstream with
> packaging changes in other files might be a matter of opinion
> (I'm personally quite happy that is no longer possible), but
> debian/control should really be something you should
Thomas Goirand writes:
> On 03/07/2012 06:33 PM, Neil Williams wrote:
>> Even with such calls, I don't see how to remove a single line from
>> a .install file using dpkg-vendor. (Typically this is necessary when
>> the line in question contains a wildcard but the modified build means
>> that no f
On 03/07/2012 06:33 PM, Neil Williams wrote:
> Even with such calls, I don't see how to remove a single line from
> a .install file using dpkg-vendor. (Typically this is necessary when
> the line in question contains a wildcard but the modified build means
> that no files can exist which match said
On Wed, Mar 07, 2012 at 12:52:53PM +0100, Andreas Tille wrote:
> On Wed, Mar 07, 2012 at 11:17:44AM +0100, Michael Hanke wrote:
> >
> > Not exactly the same thing, but for backporting for various releases we
> > (NeuroDebian) quite often have to adjust the Debian packaging itself,
> > but still wa
On Wed, Mar 07, 2012 at 11:17:44AM +0100, Michael Hanke wrote:
>
> Not exactly the same thing, but for backporting for various releases we
> (NeuroDebian) quite often have to adjust the Debian packaging itself,
> but still want to have everything stored in a single source package.
> And we do stor
On Wed, 07 Mar 2012 10:27:27 +
Simon McVittie wrote:
> On 07/03/12 09:34, Neil Williams wrote:
> > Turn the problem around - if someone (me) comes to you about one
> > of your packages with a set of changes which are necessary to be
> > able to rebuild your package, say, without perl or witho
* Neil Williams [120307 10:35]:
> Not within Debian uploads and buildd's, true, but there are good reasons
> for this to remain technically possible for derivatives. The ability for
> someone downstream of Debian to patch debian/control[.in] and [...]
On the other hand that is also a very good re
On Wed, 07 Mar 2012, Neil Williams wrote:
> Quick question, therefore, what is the method of using dpkg-vendor to
> modify a postinst which uses a grep option which is not supported by
> busybox?
>
> Or a method for removing a single line from a .install file?
Like you want. One possible approach
On Wed, Mar 7, 2012 at 4:53 PM, Thomas Goirand wrote:
> I've just seen an (ugly) instance of many quilt patches in
> debian/patches that are patching things inside the debian/ folder. I am
> wondering if it would be wise to forbid this entirely, and write about
> it in the policy (maybe it is ther
Raphael Hertzog writes:
> Hi,
>
> On Wed, 07 Mar 2012, Thomas Goirand wrote:
>> I've just seen an (ugly) instance of many quilt patches in
>> debian/patches that are patching things inside the debian/ folder. I am
>> wondering if it would be wise to forbid this entirely, and write about
>> it in
On Wed, 7 Mar 2012 10:52:57 +0100
Raphael Hertzog wrote:
> On Wed, 07 Mar 2012, Thomas Goirand wrote:
> > I've just seen an (ugly) instance of many quilt patches in
> > debian/patches that are patching things inside the debian/ folder. I am
> > wondering if it would be wise to forbid this entirel
On 07/03/12 09:34, Neil Williams wrote:
> Turn the problem around - if someone (me) comes to you about one
> of your packages with a set of changes which are necessary to be
> able to rebuild your package, say, without perl or without SSL or
> without LDAP support - how would you prefer that to be
On Wed, Mar 07, 2012 at 10:52:57AM +0100, Raphael Hertzog wrote:
> It's already caught by lintian as an error:
> http://lintian.debian.org/tags/patch-modifying-debian-files.html
>
> In any case it's definitely not a good idea and it breaks when you use 3.0
> (quilt).
>
> I don't know of any valid
Hi,
On Wed, 07 Mar 2012, Thomas Goirand wrote:
> I've just seen an (ugly) instance of many quilt patches in
> debian/patches that are patching things inside the debian/ folder. I am
> wondering if it would be wise to forbid this entirely, and write about
> it in the policy (maybe it is there alrea
On Wed, 07 Mar 2012 16:53:00 +0800
Thomas Goirand wrote:
> I've just seen an (ugly) instance of many quilt patches in
> debian/patches that are patching things inside the debian/ folder. I am
> wondering if it would be wise to forbid this entirely, and write about
> it in the policy (maybe it is
Hi,
I've just seen an (ugly) instance of many quilt patches in
debian/patches that are patching things inside the debian/ folder. I am
wondering if it would be wise to forbid this entirely, and write about
it in the policy (maybe it is there already?). There's no sane reason
why this would happen:
19 matches
Mail list logo
