Re: Patch systems in packages

[Scott Kitterman]

On Wednesday 27 August 2008 16:47:24 Phillip Susi wrote:
> Emmet Hikory wrote:
> > I am not advocating the storage of patches in the diff.gz, as I
> > believe that this makes the package awkward to extend when Ubuntu
> > seeks to add patches: I'd much prefer that each package have a patch
> > system.  I understand that for work in Debian, using a VCS in place of
> > a patch system can be easier, but it's certainly not easier for
> > derivatives, especially for patches that do not belong back in Debian.
>
> Agreed.
>
> >  Rather I am arguing against the introduction of a patch system in
> > Ubuntu for packages that maintain patches in the diff.gz in Debian
> > except in the rare case where there is such a vast separation in the
> > Ubuntu and Debian packaging that it becomes easier to apply Debian
> > patches by reviewing debdiffs between Debian packages rather than
> > either using the merge tools or rebasing packaging off the Debian
> > package each time.
> >
> > 1:
> > https://lists.ubuntu.com/archives/intrepid-changes/2008-August/005755.htm
> >l
>
> Sounds like we are in agreement in principal; we just disagree exactly
> where to draw the line.  I'd rather get the pain of adding the patch
> system over sooner so it doesn't grow worse when I have to do it later.
>   Also if debian is using a VCS then it becomes fairly easy to pull the
> patches from their VCS and merge them into our VCS or patch system,
> rather than trying to do a hand merge between the two .diff.gz files.

Right, but this still leads to the difficult scenario I mentioned yesterday 
where the Debian maintainer incorporates the patch, MoM completely fails to 
notice it, and then the best thing that can happen is the package fails to 
build.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Emmet Hikory wrote:
> I am not advocating the storage of patches in the diff.gz, as I
> believe that this makes the package awkward to extend when Ubuntu
> seeks to add patches: I'd much prefer that each package have a patch
> system.  I understand that for work in Debian, using a VCS in place of
> a patch system can be easier, but it's certainly not easier for
> derivatives, especially for patches that do not belong back in Debian.

Agreed.

>  Rather I am arguing against the introduction of a patch system in
> Ubuntu for packages that maintain patches in the diff.gz in Debian
> except in the rare case where there is such a vast separation in the
> Ubuntu and Debian packaging that it becomes easier to apply Debian
> patches by reviewing debdiffs between Debian packages rather than
> either using the merge tools or rebasing packaging off the Debian
> package each time.
> 
> 1: https://lists.ubuntu.com/archives/intrepid-changes/2008-August/005755.html

Sounds like we are in agreement in principal; we just disagree exactly 
where to draw the line.  I'd rather get the pain of adding the patch 
system over sooner so it doesn't grow worse when I have to do it later. 
  Also if debian is using a VCS then it becomes fairly easy to pull the 
patches from their VCS and merge them into our VCS or patch system, 
rather than trying to do a hand merge between the two .diff.gz files.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Scott Kitterman]

One thing I think this dicussion misses is consideration of how our merge 
tools work.  Think of the case of a package with inline changes fron Debian 
and an Ubuntu change also and the Debian maintainer adds the Ubuntu change 
to hs package in Debian.

If the Ubuntu change is also in line merge-o-matic will either note this 
and drop the Ubuntu diff or conflict and leave markers in the code showing 
what needs manual review.  If the change is in a patch, it will totally 
fail to be noticed and at best cause an FTBFS that would require a lot of 
work to fully detangle.

I like patch systems, but we need to be careful not to use them when we 
could shoot ourselves in the foot as a result.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Emmet Hikory]

Phillip Susi wrote:
> Emmet Hikory wrote:
>> these trivial (but very common) cases, the work for a later Ubuntu
>> merger to discover that the patch system and attendant patches are no
>> longer relevant is of similar volume to that of an Ubuntu merger
>> presented with a couple of patches in diff.gz that must be detangled,
>> and yet the volume of work to put the pacakge in this state is
>> considerably higher, so the total volume of work for Ubuntu is larger.
>
> I disagree vehemently with this point.  The work of detangling multiple
> patches is so large as to be nearly insurmountable unless each patch is a
> simple one or two liner.  Even if you can figure out what changes correspond
> to what entry in the changelog, usually the changelog description is far
> more terse than the one accompanying the patch, which you can not recover if
> it is just merged into the main .diff.gz.  While adding a patch system makes
> the diff larger, it is generally pretty standard stuff, and so easy to
> filter out.  Even scanning the debdiff by eye, it is very simple to pick out
> the one or two dpatch files that were added from the boilerplate code, and
> easily review or separate them.
>
> If it is a single and very simple patch that requires little explanation,
> then it isn't so bad to leave it in the .diff.gz, but as soon as you start
> carrying multiple patches, or patches which are somewhat complex, you really
> need to use a VCS or patch system to track each change independently and
> with good descriptions, or you will quickly loose all control of what
> patches have been applied, what they do, and why they were needed, and how
> they work.

I think you miss my point entirely, as I agree with the assertion
that "[the] work of detangling multiple patches is so large as to be
nearly insurmountable unless each patch is a simple one or two
liner.", which is precisely why I argue against the introduction of a
patch system in cases where the patches are maintained directly in the
diff.gz in Debian: I claim it is simpler for an Ubuntu merger to
review an additional small patch maintained in the diff.gz (or even
two).  Where the package has been repackaged and the patches stored in
Debian in the diff.gz pulled into separate patches (perhaps correctly,
perhaps not, depending on the available documentation and the skill of
the person extracting the patches from the diff.gz), it directly
complicates the work of the Ubuntu merger to understand what was
changed in the diff.gz in Debian and how to integrate that into the
patch system.  This is well after one has "[lost] control of what
patches have been applied, what they do, and why they were needed, and
how they work" within the diff.gz.  If I take as an example the recent
merge of dibbler (1): consider the case where the Debian maintainer
may in future make two unrelated changes that happen to touch the same
single file in the diff.gz.  How is the Ubuntu merger to handle that?
Are they to detangle these changes in order to fit them into the
introduced patch system?  Are they to create a new
debian/patches/debian_random_changes.dpatch to contain them?  Would it
not have been simpler *for the Ubuntu merger* to have the meaningful
1-line patch also stored in the diff.gz?  While storing it there does
require a slightly more verbose changelog entry to make sure that the
patch is understood, it seems to be less likely to cause issues in the
future, especially as the merger in one cycle may well not be the
merger in the next cycle.  The advantage of minimising the monolithic
debdiff as presented on the PTS is not only for the Debian maintainer,
but also for the Ubuntu merger who is trying to understand what
changed, and where, and why.

I am not advocating the storage of patches in the diff.gz, as I
believe that this makes the package awkward to extend when Ubuntu
seeks to add patches: I'd much prefer that each package have a patch
system.  I understand that for work in Debian, using a VCS in place of
a patch system can be easier, but it's certainly not easier for
derivatives, especially for patches that do not belong back in Debian.
 Rather I am arguing against the introduction of a patch system in
Ubuntu for packages that maintain patches in the diff.gz in Debian
except in the rare case where there is such a vast separation in the
Ubuntu and Debian packaging that it becomes easier to apply Debian
patches by reviewing debdiffs between Debian packages rather than
either using the merge tools or rebasing packaging off the Debian
package each time.

1: https://lists.ubuntu.com/archives/intrepid-changes/2008-August/005755.html

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Scott Kitterman wrote:
>> Has debian policy changed in the last few years?
> 
> No, but in Debian, policy follows practice.  It doesn't leadt it.  The 
> current flirtation with various DVCS seems to have pushed things in this 
> direction.  Unfortunately this leaves all the structure in the DVCS and not 
> in the package.

Yes, and that's the down side of using a DVCS, but at least the 
information that is missing from the source package is available 
_somewhere_ ( in the vcs ).  If you just modify the original sources 
directly without a patch system, then you don't have the information 
(detailed description of each patch, delineation between each patch ) 
_anywhere_.



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Stephan Hermann wrote:
> Again, we don't have to discuss the pros and cons of a patch system. We
> have them, and we should use them, but on Ubuntu, when the original
> maintainer in debian doesn't use a patch system, we shouldn't introduce
> one but using the way the debian maintainer is using.

If the debian maintainer has a patch system, then sure, you should use 
that one instead of adding another.  If they don't have one though, we 
have just as much reason to add one in ubuntu as they do in debian.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Stefan Potyra wrote:
> This is quite a good example, why I personally believe that patch systems for 
> universe packages shouldn't be added: Assuming that a patch is still relevant 
> and functional because it applies cleanly (or the other way round) is quite a 
> flawed approach. You should in all cases verify that this is the case, no 
> matter if you use a patch system or don't use one.

My point was that figuring that out is MUCH easier when you don't have 3 
different patches all smashed into one, with little to no documentation. 
   Since we seem to agree that use of a patch system is good, I don't 
see how you can conclude that using them in universe packages isn't.

> And exactly this logic ("it applies, so it must be correct") is something 
> I've 
> seen quite a bit when sponsoring packages, in particular merges: People are 
> easily tempted to take the output of MoM/DaD as granted if it seems to work, 
> w.o. looking at the ubuntu delta in particular or if each change is still 
> needed.

I don't see how this is related to the use of a patch system or not.

> Finally, for universe packages the number of patches is usually quite low, so 
> I don't see any problem with applying these inline when there isn't a patch 
> system present yet.

If it is a single trivial change, that's fine, but once you have more 
than one change, applying them inline gets them hopelessly tangled and 
makes sorting out what's what much, much harder.

> What's more important is that changes are properly documented, especially the 
> why and how a change was done, and that the changes are forwarded upstream. 
> However this is an educational problem, which can imho not be solved just by 
> using a patch system.

Use of a patch system allows for this since each change is split in its 
own patch, and accompanied with documentation.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Emmet Hikory wrote:
> Actually, the monolithic patch that the Debian Maintainer
> frequently doesn't want to see is the debdiff from the ubuntu version,
> rather than the raw diff.gz.  This is presented by default on the PTS,
> and can be useful for some packages, but is often not the best way to
> see the results.  When there is a simple patch, this debdiff can be
> clean, regardless of how the patch is applied.  When a patch system is
> introduced in Ubuntu to a package that does not have a patch system in
> Debian, this debdiff will be less clean, and if the patch system
> chosen in Ubuntu is not one preferred by the Debian Maintainer, it
> means that the fix requires more than just applying the patch after
> filtering out the changelog and maintainer change.  More generally, if
> the Debian Maintainer uses e.g. quilt, this debdiff ought contain a
> quilt-formatted patch: the same ought be true for packages using
> simple-patchsys, dpatch, a custom-hacked patch system in debian/rules,
> or changes raw in diff.gz.

That's why you don't send the debian maintainer the debdiff.  You send 
him the individual patch(es), and let him worry about applying them 
using whatever patch system, or lack of one, that he chooses.  Even if 
he looks at the debdiff, picking out the individual patches is trivial, 
at least with dpatch.

> How does this become differently clear?  If the package in
> question uses a patch system in Debian, then there is no debate.  If
> the package in question does not use a patch system in Debian, the
> introduction of a patch system and attendant repackaging may appear to
> be a voluminous change to the Debian changes (and is), while the
> actual patch of interest was an upstream patch exclusively.  I submit
> that changing the choice of patch system (or none) is significantly
> more frustrating to a Debian Maintainer than applying a patch
> following the practice used in Debian.

I agree with that.  If you try to send the debdiff to the debian 
maintainer it will be frustrating to him.  This is easily solved though 
by just sending him the patch instead.  While it is good to be concerned 
about debian, maintaining the package in ubuntu is more important, and 
doing so requires a reasonable patch management system.  It seems you 
are trying to make it trivially easy for a debian dev to import a 
trivial patch from an ubuntu derivative at the expense of making 
maintaining the ubuntu package much more difficult.

> All of the above notwithstanding, I do agree with Steve that where
> there are a significant number of Ubuntu changes, especially where
> many of them are not expected to go to Debian, it makes sense to track
> the patches in Ubuntu, rather than in the Debian BTS.  In these cases,
> I think it's appropriate to use a patch system if present, branch a
> VCS if Debian code is in a VCS and no patch system is present,
> introduce a patch system matching the Debian Maintainer's apparent
> preference, or introduce a new patch system in Ubuntu, with preference
> in that order.  On the other hand, I don't think this overhead is
> necessarily worthwhile for something small for a package well
> maintained in Debian and for which the patch is useful to Debian.  In

I generally agree, but what seems a single, simple, small change at the 
time can easily grow more complicated quickly, so it's a good idea to 
start using a VCS or patch system with the first change, so you don't 
have to add it later.

> these trivial (but very common) cases, the work for a later Ubuntu
> merger to discover that the patch system and attendant patches are no
> longer relevant is of similar volume to that of an Ubuntu merger
> presented with a couple of patches in diff.gz that must be detangled,
> and yet the volume of work to put the pacakge in this state is
> considerably higher, so the total volume of work for Ubuntu is larger.

I disagree vehemently with this point.  The work of detangling multiple 
patches is so large as to be nearly insurmountable unless each patch is 
a simple one or two liner.  Even if you can figure out what changes 
correspond to what entry in the changelog, usually the changelog 
description is far more terse than the one accompanying the patch, which 
you can not recover if it is just merged into the main .diff.gz.  While 
adding a patch system makes the diff larger, it is generally pretty 
standard stuff, and so easy to filter out.  Even scanning the debdiff by 
eye, it is very simple to pick out the one or two dpatch files that were 
added from the boilerplate code, and easily review or separate them.

If it is a single and very simple patch that requires little 
explanation, then it isn't so bad to leave it in the .diff.gz, but as 
soon as you start carrying multiple patches, or patches which are 
somewhat complex, you really need to use a VCS or patch system to track 
each change independently and with good descriptions, or you will 
quickly loose all control of what pa

Re: Patch systems in packages

[Stefan Potyra]

Hi,

On Thursday 21 August 2008 22:36:20 Phillip Susi wrote:
[..]
> With a patch system the old 
> .diff.gz will always apply cleanly to a new upstream tarball since it
> only adds files to debian/, and then when you build it tries to apply
> each patch individually and if one fails, disabling it or fixing it is
> much simpler when you are dealing with an individual smaller patch with
> its own documentation.

This is quite a good example, why I personally believe that patch systems for 
universe packages shouldn't be added: Assuming that a patch is still relevant 
and functional because it applies cleanly (or the other way round) is quite a 
flawed approach. You should in all cases verify that this is the case, no 
matter if you use a patch system or don't use one.

And exactly this logic ("it applies, so it must be correct") is something I've 
seen quite a bit when sponsoring packages, in particular merges: People are 
easily tempted to take the output of MoM/DaD as granted if it seems to work, 
w.o. looking at the ubuntu delta in particular or if each change is still 
needed.

Finally, for universe packages the number of patches is usually quite low, so 
I don't see any problem with applying these inline when there isn't a patch 
system present yet.
What's more important is that changes are properly documented, especially the 
why and how a change was done, and that the changes are forwarded upstream. 
However this is an educational problem, which can imho not be solved just by 
using a patch system.

Cheers,
Stefan.


signature.asc
Description: This is a digitally signed message part.
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Emmet Hikory]

Phillip Susi wrote:
> Emmet Hikory wrote:
>>Why?  Why should the Debian Maintainer care about the monolithic
>> patch as applied in Ubuntu (perhaps also cluttered by several
>> changelog entries about merges that have happened, or rebuilds).  Is
>> it not best practice to send those patches relevant to Debian to bugs
>> in the BTS, as separated patches?  If this is done, to whom is it
>> useful to track the patches independently, so long as the patches
>> remain easy to maintain?
>
> You just answered your own question.  The Debian Maintainer does not
> want to see a monolithic patch that includes all of the debianization
> and changes already there in the debian package.  He just wants the one
> new patch you have added, broken out on its own.  Tracking the patches
> independently is useful to everyone who wants the patches to remain easy
> to maintain.

Actually, the monolithic patch that the Debian Maintainer
frequently doesn't want to see is the debdiff from the ubuntu version,
rather than the raw diff.gz.  This is presented by default on the PTS,
and can be useful for some packages, but is often not the best way to
see the results.  When there is a simple patch, this debdiff can be
clean, regardless of how the patch is applied.  When a patch system is
introduced in Ubuntu to a package that does not have a patch system in
Debian, this debdiff will be less clean, and if the patch system
chosen in Ubuntu is not one preferred by the Debian Maintainer, it
means that the fix requires more than just applying the patch after
filtering out the changelog and maintainer change.  More generally, if
the Debian Maintainer uses e.g. quilt, this debdiff ought contain a
quilt-formatted patch: the same ought be true for packages using
simple-patchsys, dpatch, a custom-hacked patch system in debian/rules,
or changes raw in diff.gz.

>>I generally argue against the introduction of patch systems, as 1)
>> I am very much opposed to working with a package that has both changes
>> in diff.gz (from the original packaging), and 2) a patch system.
>
> Yes, there should be no changes in the .diff.gz outside of debian/ ( at
> least when not using a proper VCS ).

This is precisely not what I am saying.  When a package is
introduced in Debian, I agree with you completely.  When a package
that uses a VCS in Debian and stores patches in diff.gz, I do not
believe it is appropriate for Ubuntu to introduce a patch system.
This either results in a package that makes changes external to
debian/ in both the diff.gz and a patch system, or requires that the
diff.gz changes be unwound to work with a patch system.  In cases
where the package assumes that the patches will be applied before
running debian/rules clean, this can be especially confusing and turn
what ought to have been a simple patch into a long and complicated
repackaging process.  It is a far superior model to follow the
practice of the existing source package and send the patch of interest
to the BTS for individual tracking.

>> These are painfully ugly, and the monolithic diff frequently becomes
>> completely unreadable (was this a change to a previous Debian change,
>> to an upstream change, or to a combination?); and 2) I have heard a
>
> That's exactly WHY all changes to the original sources should be done
> via a patch system; so that it is immediately clear when you are
> changing the debian changes, or applying a patch to the upstream source.

How does this become differently clear?  If the package in
question uses a patch system in Debian, then there is no debate.  If
the package in question does not use a patch system in Debian, the
introduction of a patch system and attendant repackaging may appear to
be a voluminous change to the Debian changes (and is), while the
actual patch of interest was an upstream patch exclusively.  I submit
that changing the choice of patch system (or none) is significantly
more frustrating to a Debian Maintainer than applying a patch
following the practice used in Debian.

>> number of Debian maintainers complain about the "useless" introduction
>> of a patch system when they maintain the package in a VCS with no
>> patch system.  That said, in the case where there are no previous
>> diff.gz changes external to debian/, I think it is best practice to
>> review other packages with the same Debian Maintainer to attempt to
>> determine the preferred patch system of that maintainer (which may be
>> monolithic diff.gz), and follow that practice.  In the rare case where
>> there are no patches external to debian/ in any of the packages
>> maintained by that Maintainer, the introduction of a patch system
>> seems the least bad way to do things, but this is very much an
>> exceptional case, and for most packages we would do well to instead
>> follow the existing practice (even where that is a monolithic
>> diff.gz).
>
> VCS throws a big wrench it the works since it totally clashes with the
> debian package system, which essentia

Re: Patch systems in packages

[Stephan Hermann]

On Thu, Aug 21, 2008 at 04:36:20PM -0400, Phillip Susi wrote:
> Stephan Hermann wrote:
> > I think the problem is, that many people don't know, that debian
> > source packages do have this diff.gz handling, which is also a "patch"
> > system. Not the best one, but actually it works.
> 
> And that's exactly the problem.  You don't WANT patches munged up into
> the single massive .diff.gz because then it becomes extremely hard to do
> things like fix them so they apply cleanly to a new upstream, or break
> them out and send them to upstream to apply, or easily remove them once
> upstream has accepted the patch.

I never said, you should do it...but you have packages where this
behaviour (debianized tree, patching sources directly in this tree,
changes are in .diff.gz) is used (with or without intention), and it's a
legal way to do it. 
If this way is a good one, this is written on another paper :)

> 
> > A debianized source tree (with debian/ already applied) can be changed
> > outside debian/ dir and those changes are going in the resulting
> > diff.gz. No orig.tar.gz source is being touched.
> 
> And then when you drop in a new .orig.tar.gz from upstream, you have
> dozens of errors applying the .diff.gz and since it's all one monolithic
> patch, it's much, much harder to sort out.  With a patch system the old
> .diff.gz will always apply cleanly to a new upstream tarball since it
> only adds files to debian/, and then when you build it tries to apply
> each patch individually and if one fails, disabling it or fixing it is
> much simpler when you are dealing with an individual smaller patch with
> its own documentation.

Again, we don't have to discuss the pros and cons of a patch system. We
have them, and we should use them, but on Ubuntu, when the original
maintainer in debian doesn't use a patch system, we shouldn't introduce
one but using the way the debian maintainer is using.


Regards,
\sh

-- 
Stephan '\sh' Hermann   | OSS Developer & Systemadministrator
JID: [EMAIL PROTECTED]  | http://www.sourcecode.de/
GPG ID: 0xC098EFA8  | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Scott Kitterman]

On Thu, 21 Aug 2008 16:35:31 -0400 Phillip Susi <[EMAIL PROTECTED]> wrote:
>Reinhard Tartler wrote:
>> I really wonder who brought up the (wrong) claim that *not* using a
>> patch system was deprecated in the first place.
>
>It isn't deprecated; it's something you were never supposed to do.
>
>>> In the first case, if you are going to start patching you need to use
>>> one of the patch systems to do it. 
>> 
>> I disagree with the necessity with doing that. And I strongly disagree
>> telling Debian Developers to use one.
>
>The last time I read the debian packaging guide it was debian developers
>telling ME to use a patch system, and not to modify the original
>upstream files directly.  This was reinforced by lintian complaining
>loudly if you do so, and I had packages rejected for doing this.  It
>certainly makes managing the changes across several versions ( both
>local and upstream ) much easier.  When you add more than one trivial
>patch without a patch system it becomes impossible to manage them since
>they get merged into one large patch, so you have a hard time pulling
>just one back out, or sending it upstream, or fixing it to apply cleanly
>to a new upstream version.
>
>Has debian policy changed in the last few years?

No, but in Debian, policy follows practice.  It doesn't leadt it.  The 
current flirtation with various DVCS seems to have pushed things in this 
direction.  Unfortunately this leaves all the structure in the DVCS and not 
in the package.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Emmet Hikory wrote:
>> upload), or it can be an in-package patch system; but it is important to
>> have /some/ mechanism for labelling your changes so that you aren't left
>> with a single massive diff.
> 
> Why?  Why should the Debian Maintainer care about the monolithic
> patch as applied in Ubuntu (perhaps also cluttered by several
> changelog entries about merges that have happened, or rebuilds).  Is
> it not best practice to send those patches relevant to Debian to bugs
> in the BTS, as separated patches?  If this is done, to whom is it
> useful to track the patches independently, so long as the patches
> remain easy to maintain?

You just answered your own question.  The Debian Maintainer does not
want to see a monolithic patch that includes all of the debianization
and changes already there in the debian package.  He just wants the one
new patch you have added, broken out on its own.  Tracking the patches
independently is useful to everyone who wants the patches to remain easy
to maintain.

> I generally argue against the introduction of patch systems, as 1)
> I am very much opposed to working with a package that has both changes
> in diff.gz (from the original packaging), and 2) a patch system.

Yes, there should be no changes in the .diff.gz outside of debian/ ( at
least when not using a proper VCS ).

> These are painfully ugly, and the monolithic diff frequently becomes
> completely unreadable (was this a change to a previous Debian change,
> to an upstream change, or to a combination?); and 2) I have heard a

That's exactly WHY all changes to the original sources should be done
via a patch system; so that it is immediately clear when you are
changing the debian changes, or applying a patch to the upstream source.

> number of Debian maintainers complain about the "useless" introduction
> of a patch system when they maintain the package in a VCS with no
> patch system.  That said, in the case where there are no previous
> diff.gz changes external to debian/, I think it is best practice to
> review other packages with the same Debian Maintainer to attempt to
> determine the preferred patch system of that maintainer (which may be
> monolithic diff.gz), and follow that practice.  In the rare case where
> there are no patches external to debian/ in any of the packages
> maintained by that Maintainer, the introduction of a patch system
> seems the least bad way to do things, but this is very much an
> exceptional case, and for most packages we would do well to instead
> follow the existing practice (even where that is a monolithic
> diff.gz).

VCS throws a big wrench it the works since it totally clashes with the
debian package system, which essentially is another form of VCS.  If you
are using a VCS, then you have to stick to the external VCS and not
bother with directly messing with the debian source package.  If you
aren't using an external VCS, then you handle change control the debian
way and use a patch system.




-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Stephan Hermann wrote:
> I think the problem is, that many people don't know, that debian
> source packages do have this diff.gz handling, which is also a "patch"
> system. Not the best one, but actually it works.

And that's exactly the problem.  You don't WANT patches munged up into
the single massive .diff.gz because then it becomes extremely hard to do
things like fix them so they apply cleanly to a new upstream, or break
them out and send them to upstream to apply, or easily remove them once
upstream has accepted the patch.

> A debianized source tree (with debian/ already applied) can be changed
> outside debian/ dir and those changes are going in the resulting
> diff.gz. No orig.tar.gz source is being touched.

And then when you drop in a new .orig.tar.gz from upstream, you have
dozens of errors applying the .diff.gz and since it's all one monolithic
patch, it's much, much harder to sort out.  With a patch system the old
.diff.gz will always apply cleanly to a new upstream tarball since it
only adds files to debian/, and then when you build it tries to apply
each patch individually and if one fails, disabling it or fixing it is
much simpler when you are dealing with an individual smaller patch with
its own documentation.




-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Reinhard Tartler wrote:
> I really wonder who brought up the (wrong) claim that *not* using a
> patch system was deprecated in the first place.

It isn't deprecated; it's something you were never supposed to do.

>> In the first case, if you are going to start patching you need to use
>> one of the patch systems to do it. 
> 
> I disagree with the necessity with doing that. And I strongly disagree
> telling Debian Developers to use one.

The last time I read the debian packaging guide it was debian developers
telling ME to use a patch system, and not to modify the original
upstream files directly.  This was reinforced by lintian complaining
loudly if you do so, and I had packages rejected for doing this.  It
certainly makes managing the changes across several versions ( both
local and upstream ) much easier.  When you add more than one trivial
patch without a patch system it becomes impossible to manage them since
they get merged into one large patch, so you have a hard time pulling
just one back out, or sending it upstream, or fixing it to apply cleanly
to a new upstream version.

Has debian policy changed in the last few years?



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Steve Langasek]

On Wed, Aug 20, 2008 at 11:31:41AM +0900, Emmet Hikory wrote:
> Steve Langasek wrote:
> > If you have more than one change to the upstream source of a Debian package,
> > then you need some system to manage the changes to indicate which parts of
> > the patch belong to which functional change -- i.e., a "patch management
> > system".  This can be a set of VCS feature branches, if you prefer (in which
> > case it's important to use the Vcs-* headers in debian/control in the Ubuntu
> > upload), or it can be an in-package patch system; but it is important to
> > have /some/ mechanism for labelling your changes so that you aren't left
> > with a single massive diff.

> Why?  Why should the Debian Maintainer care about the monolithic
> patch as applied in Ubuntu (perhaps also cluttered by several
> changelog entries about merges that have happened, or rebuilds).  Is
> it not best practice to send those patches relevant to Debian to bugs
> in the BTS, as separated patches?  If this is done, to whom is it
> useful to track the patches independently, so long as the patches
> remain easy to maintain?

I think this is a misleading question:  it is /not/ easy to maintain patches
that are jumbled together in a monolithic diff, because even if it's easy
for the person who created the patches (which is likely to change over
time), it's not necessarily easy for $random_other_ubuntu_developer who
comes along afterwards.  Even the most innocuous-seeming of patches can
become head-scratchers over time if they aren't accompanied by appropriate
metadata (description, + some sort of bounding box saying which bits
belong).

So for *Ubuntu's* benefit, I believe our best practices should be to use
some sort of patch management whenever patching upstream sources, not just a
monolithic diff.  (Again, I think this can be either VCS feature branches or
an in-package patch system, whichever is easier for the people doing the
work.)

> > If the Debian maintainer already has a patch system in place, it's far
> > better to continue using that one (no matter how bad it is, sometimes);
> > otherwise, adding a patch system *should* be done when needed.

> I generally argue against the introduction of patch systems, as 1)
> I am very much opposed to working with a package that has both changes
> in diff.gz (from the original packaging), and 2) a patch system.

If we're talking about packages where the Debian maintainer has already
patched upstream and done so without a patch system, then I agree that this
is ugly; in that case I think the best outcome is if the Debian maintainer
can be persuaded to /use/ some form of patch management.

> These are painfully ugly, and the monolithic diff frequently becomes
> completely unreadable (was this a change to a previous Debian change,
> to an upstream change, or to a combination?); and 2) I have heard a
> number of Debian maintainers complain about the "useless" introduction
> of a patch system when they maintain the package in a VCS with no
> patch system.

Can you give examples of these?  Ideally if the maintainer is already using
feature branches in a distributed VCS, Ubuntu could hook into that with its
own feature branches, and that would entirely satisfy my concerns about
maintainability of the patches.  But the highest percentage of Vcs-* fields
in Debian packages still point at subversion, which is not at all useful for
this purpose.

> That said, in the case where there are no previous diff.gz changes
> external to debian/, I think it is best practice to review other packages
> with the same Debian Maintainer to attempt to determine the preferred
> patch system of that maintainer (which may be monolithic diff.gz), and
> follow that practice.  In the rare case where there are no patches
> external to debian/ in any of the packages maintained by that Maintainer,
> the introduction of a patch system seems the least bad way to do things,
> but this is very much an exceptional case, and for most packages we would
> do well to instead follow the existing practice (even where that is a
> monolithic diff.gz).

I agree; I was assuming the common case was that the Debian package did not
include patches to the upstream source, or that if there were any such
patches, they were managed with a patch system.  Perhaps this is not such a
common case as I believed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Robert Collins]

On Wed, 2008-08-20 at 12:29 -0700, Steve Langasek wrote:


> > Why?  Why should the Debian Maintainer care about the monolithic
> > patch as applied in Ubuntu (perhaps also cluttered by several
> > changelog entries about merges that have happened, or rebuilds).  Is
> > it not best practice to send those patches relevant to Debian to bugs
> > in the BTS, as separated patches?  If this is done, to whom is it
> > useful to track the patches independently, so long as the patches
> > remain easy to maintain?
> 
> I think this is a misleading question:  it is /not/ easy to maintain patches
> that are jumbled together in a monolithic diff, because even if it's easy
> for the person who created the patches (which is likely to change over
> time), it's not necessarily easy for $random_other_ubuntu_developer who
> comes along afterwards.  Even the most innocuous-seeming of patches can
> become head-scratchers over time if they aren't accompanied by appropriate
> metadata (description, + some sort of bounding box saying which bits
> belong).

And yet, upstream development proceeds by editing a single huge
monolithic diff (NULL->BRANCH_TIP) :). 

The key difference IMO is that when you have a bunch of patches that
have not yet been reviewed, its likely that some will be accepted, and
some not - and its harder to detangle those two sets after the fact. But
making incremental changes is no harder with a monolithic patch than a
set of itemised patches - and in some respects a monolithic patch is
easier.

> So for *Ubuntu's* benefit, I believe our best practices should be to use
> some sort of patch management whenever patching upstream sources, not just a
> monolithic diff.  (Again, I think this can be either VCS feature branches or
> an in-package patch system, whichever is easier for the people doing the
> work.)

Agreed.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Stephan Hermann]

On Wed, Aug 20, 2008 at 07:23:27AM +0200, Reinhard Tartler wrote:
> Phillip Susi <[EMAIL PROTECTED]> writes:
> 
> > If you run into a package that does not already have some kind of
> > patch system there are 2 possibilities:
> >
> > 1)  The package has never needed to be patched before
> > 2)  The package has been patched by directly modifying the original
> > upstream files, which is a big no-no
> >
> > In the second case, the package should be fixed and the upstream debian
> > maintainer notified and asked to repair their broken package as well.
> 
> In that case, I kindly ask you to not touch any of the package I
> maintain in debian. I very much prefer managing patches to sources using
> a VCS, and adding patch system adds unnecessary noise in the debdiff.
> 
> I really wonder who brought up the (wrong) claim that *not* using a
> patch system was deprecated in the first place.

I think the problem is, that many people don't know, that debian
source packages do have this diff.gz handling, which is also a "patch"
system. Not the best one, but actually it works.

A debianized source tree (with debian/ already applied) can be changed
outside debian/ dir and those changes are going in the resulting
diff.gz. No orig.tar.gz source is being touched.

I do the same...a source package which doesn't have a patch system (like
dpatch, cdbs-simple-patchsys, quilt, or even dokos python patch system
,-)) applied, will go with diff.gz. Or, if it's possible and I have the
time, I'll get a VCS branch and do what the debian maintainer did.

As Lars said, we have everything in place...

Only packages I introduced in Ubuntu will have explicit patch system in
future (like I did now e.g. for zend-framework). So others and
especially I can track the patches I applied from upstream.

Regards,

\sh
-- 
Stephan '\sh' Hermann   | OSS Developer & Systemadministrator
JID: [EMAIL PROTECTED]  | http://www.sourcecode.de/
GPG ID: 0xC098EFA8  | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Reinhard Tartler]

Phillip Susi <[EMAIL PROTECTED]> writes:

> If you run into a package that does not already have some kind of
> patch system there are 2 possibilities:
>
> 1)  The package has never needed to be patched before
> 2)  The package has been patched by directly modifying the original
> upstream files, which is a big no-no
>
> In the second case, the package should be fixed and the upstream debian
> maintainer notified and asked to repair their broken package as well.

In that case, I kindly ask you to not touch any of the package I
maintain in debian. I very much prefer managing patches to sources using
a VCS, and adding patch system adds unnecessary noise in the debdiff.

I really wonder who brought up the (wrong) claim that *not* using a
patch system was deprecated in the first place.

> In the first case, if you are going to start patching you need to use
> one of the patch systems to do it. 

I disagree with the necessity with doing that. And I strongly disagree
telling Debian Developers to use one.

However, after reading this thread a bit more, I can agree that adding a
patch system can make sense if the following applies:

 - the package does not have any source patches outside debian/ yet
 - the package can trivially extended with a patch system
 - the patch is not trivial

Rationale: It does not really make sense to introduce quilt or dpatch
for a 2 line manpage patch. that can very easily obtained using
filterdiff on the diff.gz.

For more complicated patches that really need commenting, I can see that
patches really should be documented. E.g. I have been doing that in the
ffmpeg package, cf. the patches in [1].

http://svn.debian.org/viewsvn/pkg-multimedia/unstable/ffmpeg/debian/patches/

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Steve Langasek]

On Sat, Aug 16, 2008 at 11:31:27PM -0700, Jordan Mantha wrote:
> On Sat, Aug 16, 2008 at 9:49 PM, Nicolas Valcarcel
> <[EMAIL PROTECTED]> wrote:

> >Currently there is no policy about how to make changes in the 
> > packages,
> > there are some good practices and a lot of developers try to use patch
> > systems whenever they can and don't touch the source code outside
> > debian/ directly, but that's still at the developer's discretion.
> >For that reason i wanted to start a discussion on the topic, to start
> > working with debian on preparing the packages with a patch system, so we
> > (and other derivatives) can make patches without the need of changing
> > the packaging. Also i will suggest to the revu reviewers to ask the
> > packagers to add a patch system on their packages.
> >What did you think about it? Any comments?

> > 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195

> I think our job as downstreams is to provide patches to Debian, not
> tell them how to maintain their packages. IMO anyway, it's our
> obligation to either 1) give ordinary diff patches 2) use whatever
> patch system or lack thereof that upstream uses. There are so many
> common ways to patch and maintain a package (debhelper, cdbs, quilt,
> dpatch, svn, git, bzr ...) that I can't foresee a comprehensive,
> archive-wide policy.

> Additionally, IMO again, a primary goal of at least MOTU should be
> minimizing the divergence from Debian. The more changes we make, and
> the more useless they are (bumping standards version??) the more time
> we spend maintaining the divergence and the less time we have for more
> important tasks. Adding a patch system really *should not* be done in
> Ubuntu. If we're maintaining that much divergence we need to talk to
> Debian about how we can better minimize and maintain it.

If you have more than one change to the upstream source of a Debian package,
then you need some system to manage the changes to indicate which parts of
the patch belong to which functional change -- i.e., a "patch management
system".  This can be a set of VCS feature branches, if you prefer (in which
case it's important to use the Vcs-* headers in debian/control in the Ubuntu
upload), or it can be an in-package patch system; but it is important to
have /some/ mechanism for labelling your changes so that you aren't left
with a single massive diff.

If the Debian maintainer already has a patch system in place, it's far
better to continue using that one (no matter how bad it is, sometimes);
otherwise, adding a patch system *should* be done when needed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Emmet Hikory]

Steve Langasek wrote:
> If you have more than one change to the upstream source of a Debian package,
> then you need some system to manage the changes to indicate which parts of
> the patch belong to which functional change -- i.e., a "patch management
> system".  This can be a set of VCS feature branches, if you prefer (in which
> case it's important to use the Vcs-* headers in debian/control in the Ubuntu
> upload), or it can be an in-package patch system; but it is important to
> have /some/ mechanism for labelling your changes so that you aren't left
> with a single massive diff.

Why?  Why should the Debian Maintainer care about the monolithic
patch as applied in Ubuntu (perhaps also cluttered by several
changelog entries about merges that have happened, or rebuilds).  Is
it not best practice to send those patches relevant to Debian to bugs
in the BTS, as separated patches?  If this is done, to whom is it
useful to track the patches independently, so long as the patches
remain easy to maintain?

> If the Debian maintainer already has a patch system in place, it's far
> better to continue using that one (no matter how bad it is, sometimes);
> otherwise, adding a patch system *should* be done when needed.

I generally argue against the introduction of patch systems, as 1)
I am very much opposed to working with a package that has both changes
in diff.gz (from the original packaging), and 2) a patch system.
These are painfully ugly, and the monolithic diff frequently becomes
completely unreadable (was this a change to a previous Debian change,
to an upstream change, or to a combination?); and 2) I have heard a
number of Debian maintainers complain about the "useless" introduction
of a patch system when they maintain the package in a VCS with no
patch system.  That said, in the case where there are no previous
diff.gz changes external to debian/, I think it is best practice to
review other packages with the same Debian Maintainer to attempt to
determine the preferred patch system of that maintainer (which may be
monolithic diff.gz), and follow that practice.  In the rare case where
there are no patches external to debian/ in any of the packages
maintained by that Maintainer, the introduction of a patch system
seems the least bad way to do things, but this is very much an
exceptional case, and for most packages we would do well to instead
follow the existing practice (even where that is a monolithic
diff.gz).

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Scott Kitterman]

On Tuesday 19 August 2008 16:41, Lars Wirzenius wrote:
> ti, 2008-08-19 kello 16:34 -0400, Phillip Susi kirjoitti:
> > I have to disagree.  If you are applying patches you must use a patch
> > system to comply with the debian packaging guidelines ( otherwise you
> > modify the .orig.tar.gz and you shouldn't be doing that ).
>
> That's not actually correct. The Debian packaging tools don't require
> you to modify .orig.tar.gz if you're not using a patch system: instead,
> any changes you make outside debian/ end up in .diff.gz, just like the
> changes you make inside debian/.

Yes and our merge tools generally handle this case very well.  I support using 
patch systems, but if the Debian maintainer hasn't bothered, I think it's not 
worth the trouble for us to add it.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Robert Collins]

On Tue, 2008-08-19 at 16:34 -0400, Phillip Susi wrote:
> 
> I have to disagree.  If you are applying patches you must use a patch 
> system to comply with the debian packaging guidelines ( otherwise you 
> modify the .orig.tar.gz and you shouldn't be doing that ).

Where did this meme turn up? As Lars says, the packaging toolchain
happily supports changes of most sorts anywhere in the cleaned source
tree and will happily detect and place in the debian diff changes
outside of debian.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Lars Wirzenius]

ti, 2008-08-19 kello 16:34 -0400, Phillip Susi kirjoitti:
> I have to disagree.  If you are applying patches you must use a patch 
> system to comply with the debian packaging guidelines ( otherwise you 
> modify the .orig.tar.gz and you shouldn't be doing that ).

That's not actually correct. The Debian packaging tools don't require
you to modify .orig.tar.gz if you're not using a patch system: instead,
any changes you make outside debian/ end up in .diff.gz, just like the
changes you make inside debian/.



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Phillip Susi]

Reinhard Tartler wrote:
>> I think our job as downstreams is to provide patches to Debian, not
>> tell them how to maintain their packages.
> 
> Excatly.
> 
> Please note that adding a patch system to a package that previously
> didn't adds additional noise in the debdiff. So please, don't.
> 
> (well, perhaps debdiff could be taught somehow to handle patch systems
> more sensibly, which would alleviate the issue here)

I have to disagree.  If you are applying patches you must use a patch 
system to comply with the debian packaging guidelines ( otherwise you 
modify the .orig.tar.gz and you shouldn't be doing that ).  If you run 
into a package that does not already have some kind of patch system 
there are 2 possibilities:

1)  The package has never needed to be patched before
2)  The package has been patched by directly modifying the original 
upstream files, which is a big no-no

In the second case, the package should be fixed and the upstream debian 
maintainer notified and asked to repair their broken package as well.

In the first case, if you are going to start patching you need to use 
one of the patch systems to do it.  Ideally you would want to coordinate 
with the debian package maintainer to use whichever patch system he 
prefers so he will accept the diff adding the patch and the patch 
system.  Practically speaking though, it can take weeks, months, or 
sometimes years to get a debian developer to pay attention to your 
patch, so really you just want to go ahead and diverge by adding a patch 
system, try to get it added to debian, and if the debian maintainer ever 
manages to add the patch, even if he uses a different patch system, you 
can just drop the ubuntu changes when merging from debian.

Sure, you will have to manually merge debian updates until they accept 
the patch, but using the patch system in the first place makes this as 
simple as grabbing the debian package, inserting the patch system again, 
and copying over the patch file from the last ubuntu package.



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Reinhard Tartler]

"Jordan Mantha" <[EMAIL PROTECTED]> writes:

> Also i will suggest to the revu reviewers to ask the
>> packagers to add a patch system on their packages.
>>What did you think about it? Any comments?
>>
>
> I think our job as downstreams is to provide patches to Debian, not
> tell them how to maintain their packages.

Excatly.

Please note that adding a patch system to a package that previously
didn't adds additional noise in the debdiff. So please, don't.

(well, perhaps debdiff could be taught somehow to handle patch systems
more sensibly, which would alleviate the issue here)

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Jordan Mantha]

On Tue, Aug 19, 2008 at 9:25 AM, Steve Langasek
<[EMAIL PROTECTED]> wrote:
> On Sat, Aug 16, 2008 at 11:31:27PM -0700, Jordan Mantha wrote:
>> On Sat, Aug 16, 2008 at 9:49 PM, Nicolas Valcarcel
>> <[EMAIL PROTECTED]> wrote:
>
>> >Currently there is no policy about how to make changes in the 
>> > packages,
>> > there are some good practices and a lot of developers try to use patch
>> > systems whenever they can and don't touch the source code outside
>> > debian/ directly, but that's still at the developer's discretion.
>> >For that reason i wanted to start a discussion on the topic, to 
>> > start
>> > working with debian on preparing the packages with a patch system, so we
>> > (and other derivatives) can make patches without the need of changing
>> > the packaging. Also i will suggest to the revu reviewers to ask the
>> > packagers to add a patch system on their packages.
>> >What did you think about it? Any comments?
>
>> > 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195
>
>> I think our job as downstreams is to provide patches to Debian, not
>> tell them how to maintain their packages. IMO anyway, it's our
>> obligation to either 1) give ordinary diff patches 2) use whatever
>> patch system or lack thereof that upstream uses. There are so many
>> common ways to patch and maintain a package (debhelper, cdbs, quilt,
>> dpatch, svn, git, bzr ...) that I can't foresee a comprehensive,
>> archive-wide policy.
>
>> Additionally, IMO again, a primary goal of at least MOTU should be
>> minimizing the divergence from Debian. The more changes we make, and
>> the more useless they are (bumping standards version??) the more time
>> we spend maintaining the divergence and the less time we have for more
>> important tasks. Adding a patch system really *should not* be done in
>> Ubuntu. If we're maintaining that much divergence we need to talk to
>> Debian about how we can better minimize and maintain it.
>
> If you have more than one change to the upstream source of a Debian package,
> then you need some system to manage the changes to indicate which parts of
> the patch belong to which functional change -- i.e., a "patch management
> system".  This can be a set of VCS feature branches, if you prefer (in which
> case it's important to use the Vcs-* headers in debian/control in the Ubuntu
> upload), or it can be an in-package patch system; but it is important to
> have /some/ mechanism for labelling your changes so that you aren't left
> with a single massive diff.

My point was that if people are pushing patches upstream and talking
with Debian maintainers then I imagine Ubuntu adding a patch system
would be a quite rare occurrence. Certainly in Universe this should be
the case. Main seems to have more Ubuntu-side maintenance so I can see
it happening more there.

> If the Debian maintainer already has a patch system in place, it's far
> better to continue using that one (no matter how bad it is, sometimes);
> otherwise, adding a patch system *should* be done when needed.

For sure, I'm just saying that it's probably in our best interest to
not let divergence from Debian get so far that the "when needed" kicks
in. Most packages that have heavy patching usually already have a
patch system. For the not-so-often-patched packages it's better to
move changes upstream.

-Jordan

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Scott Kitterman]

On Sunday 17 August 2008 01:37, Nicolas Valcarcel wrote:
> On Sun, 2008-08-17 at 01:27 -0400, Scott Kitterman wrote:
> > For Debian, many maintainers keep their packages in their favorite VCS
> > and so
> > it's less relevant as a policy issue.
>
> Yes, but for the debian maintainers it will be easy to check for
> separate patches on the debian derivatives than reading a big diff
> including a lot of changes.

Which is why as a good downstream we should be filing bugs with explicit 
explanation of the patch and the patch in the upstream BTS.  

Even in cases where I'm the Debian maintainer and I made the change in Ubuntu 
I find the monlithic patches that get linked into PTS hard to deal with.  In 
all the hundreds of uploads I've done, I can only recall one occasion where a 
Debian maintainer changed something based on just that patch.  OTOH, I've had 
great success with bugs that have a good rationale and a patch.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Jordan Mantha]

On Sat, Aug 16, 2008 at 9:49 PM, Nicolas Valcarcel
<[EMAIL PROTECTED]> wrote:
> Hi!
>Currently there is no policy about how to make changes in the packages,
> there are some good practices and a lot of developers try to use patch
> systems whenever they can and don't touch the source code outside
> debian/ directly, but that's still at the developer's discretion.
>For that reason i wanted to start a discussion on the topic, to start
> working with debian on preparing the packages with a patch system, so we
> (and other derivatives) can make patches without the need of changing
> the packaging. Also i will suggest to the revu reviewers to ask the
> packagers to add a patch system on their packages.
>What did you think about it? Any comments?
>
> 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195

I think our job as downstreams is to provide patches to Debian, not
tell them how to maintain their packages. IMO anyway, it's our
obligation to either 1) give ordinary diff patches 2) use whatever
patch system or lack thereof that upstream uses. There are so many
common ways to patch and maintain a package (debhelper, cdbs, quilt,
dpatch, svn, git, bzr ...) that I can't foresee a comprehensive,
archive-wide policy.

Additionally, IMO again, a primary goal of at least MOTU should be
minimizing the divergence from Debian. The more changes we make, and
the more useless they are (bumping standards version??) the more time
we spend maintaining the divergence and the less time we have for more
important tasks. Adding a patch system really *should not* be done in
Ubuntu. If we're maintaining that much divergence we need to talk to
Debian about how we can better minimize and maintain it.

-Jordan

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Justin Dugger]

On Sat, Aug 16, 2008 at 11:49 PM, Nicolas Valcarcel
<[EMAIL PROTECTED]> wrote:
> Hi!
>Currently there is no policy about how to make changes in the packages,
> there are some good practices and a lot of developers try to use patch
> systems whenever they can and don't touch the source code outside
> debian/ directly, but that's still at the developer's discretion.
>For that reason i wanted to start a discussion on the topic, to start
> working with debian on preparing the packages with a patch system, so we
> (and other derivatives) can make patches without the need of changing
> the packaging. Also i will suggest to the revu reviewers to ask the
> packagers to add a patch system on their packages.
>What did you think about it? Any comments?
>
> 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195

I feel that Daniel's right about using the upstream patch system, it's
not something Ubuntu can set a unilateral policy on and then go to
Debian with.  Debian itself doesn't have a policy, so it's up to
individual maintainers to negotiate with.  What we could do is present
a suggestion and explain how it would work, so people can at least see
why it matters and might improve things.

Call me crazy, but I think this is the sort of thing Canonical funded
bzr for. deb-src is sort of a crappy revision control system already
-- using full source package in bzr might be a good first step towards
easier collaboration with Debian.  As long as bzr and git, svn etc can
communicate patches, it shouldn't matter if one side picks one
technology over another (well Canonical might care, but I don't yet).
Basically, rather than placing patch systems into the build rules, it
seems smarter to place them in universally understood tools.  It'd be
one less speedbump between Debian and upstream as well, if Debian were
on board.

But until Debian makes DVCS policy, it seems like an increased burden
to move packages away from patch systems and carry that delta.  The
good news is that many packages are already in some form of VCS -- the
bad news is a lot aren't.  My suggestion for now is to collaborate
with upstream for now -- ask the maintainer (in this case, the
maintainer team) what their preference is.  I know the Games Team has
SVN, but if memory serves, they wanted debian dirs only, but it looks
like the git hosting uses whole package branching.  So please, don't
use a patch system without asking Debian.

Justin Dugger

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Nicolas Valcarcel]

On Sun, 2008-08-17 at 01:27 -0400, Scott Kitterman wrote:
> For Debian, many maintainers keep their packages in their favorite VCS
> and so 
> it's less relevant as a policy issue.

Yes, but for the debian maintainers it will be easy to check for
separate patches on the debian derivatives than reading a big diff
including a lot of changes.

-- 
aka nxvl
Key fingerprint = BCE4 27A0 D03E 55DE DA2D  BE06 891D 8DEE 6545 97FE
gpg --keyserver keyserver.ubuntu.com --recv-keys 654597FE



signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Patch systems in packages

[Scott Kitterman]

On Sunday 17 August 2008 00:49, Nicolas Valcarcel wrote:
> Hi!
>   Currently there is no policy about how to make changes in the packages,
> there are some good practices and a lot of developers try to use patch
> systems whenever they can and don't touch the source code outside
> debian/ directly, but that's still at the developer's discretion.
>   For that reason i wanted to start a discussion on the topic, to start
> working with debian on preparing the packages with a patch system, so we
> (and other derivatives) can make patches without the need of changing
> the packaging. Also i will suggest to the revu reviewers to ask the
> packagers to add a patch system on their packages.
>   What did you think about it? Any comments?
>
> 1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195

For Ubuntu I think this is a good idea as the only common format we have for 
team maintenance is the source package and it should stand on it's own.

For Debian, many maintainers keep their packages in their favorite VCS and so 
it's less relevant as a policy issue.

I have put comments about this on REVU, as recently as yesterday.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Patch systems in packages

[Nicolas Valcarcel]

Hi!
Currently there is no policy about how to make changes in the packages,
there are some good practices and a lot of developers try to use patch
systems whenever they can and don't touch the source code outside
debian/ directly, but that's still at the developer's discretion. 
For that reason i wanted to start a discussion on the topic, to start
working with debian on preparing the packages with a patch system, so we
(and other derivatives) can make patches without the need of changing
the packaging. Also i will suggest to the revu reviewers to ask the
packagers to add a patch system on their packages. 
What did you think about it? Any comments?

1. https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/249195

-- 
aka nxvl
Key fingerprint = BCE4 27A0 D03E 55DE DA2D  BE06 891D 8DEE 6545 97FE
gpg --keyserver keyserver.ubuntu.com --recv-keys 654597FE



signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu