Re: Patch systems in packages
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
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 patches have been applied, what they do,
Re: Patch systems in packages
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 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 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 essentially is another form of VCS. If you are using a VCS, then you have to
Re: Patch systems in packages
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
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
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
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
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
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
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: http://www.robertcollins.net/keys.txt. 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
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
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
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
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
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
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: http://www.robertcollins.net/keys.txt. 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
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
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
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
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
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
