Re: Q. about Tinkering with Debian Source Code
On Tue, Mar 26, 2019 at 8:17 AM Kent West wrote: > Oops; when to Thomas instead of list; sorry. (Gmail, ugh!) > "went", not 'when". (Kent's typing skills, ugh!) -- Forwarded message - > > On Tue, Mar 26, 2019 at 3:23 AM Thomas Schmitt wrote: > > It depends on where you plan to submit your changes. >> >> If you want to help developing the upstream software project, then work >> on a git clone and ask the upstream project people for advise how to >> contribute. >> > > If I'm understanding correctly, yea! > > Also, I'm leaning toward the understanding that if I want to make an improvement, bug-fix, etc, to the program itself, I probably want to go to the upstream maintainer (through the proper channels); if I want to make an improvement, bug-fix, etc that is specific to Debian's implementation of the program, I probably want to go to the Debian maintainer (through the proper channels). -- Kent West<")))>< Westing Peacefully - http://kentwest.blogspot.com
Fwd: Q. about Tinkering with Debian Source Code
Oops; when to Thomas instead of list; sorry. (Gmail, ugh!) -- Forwarded message - On Tue, Mar 26, 2019 at 3:23 AM Thomas Schmitt wrote: > Hi, > > Disclaimer: I am not a Debian member and only prepare the Debian packages > of my own upstream project. So i'm just one or two steps ahead of you. > > > Kent West wrote: > > Should I consider the Debian download as the official source, of the Git > > version? > > s/of/or/ ? > > Oops, my bad. Yes, "or". It depends on where you plan to submit your changes. > > If you want to help developing the upstream software project, then work > on a git clone and ask the upstream project people for advise how to > contribute. > > > > > If I start in the Debian version and it gets accepted back into Debian, > > wouldn't that make the Git version just that much more irrelevant? > > Normally you are supposed to discuss your findings and code changes with > upstream, so that your patches become obsolete with the next upstream > release. Up to then, they could fix bugs, implement new features in > advance, improve documentation, or make the package more feasable for > Debian. > > Sometimes it might be necessary to permanently deviate from upstream > decisions by permanent patches. But that should only be the last resort > if upstream cannot or does not want to follow your well motivated > proposals. > > I think this is making sense to me. An upstream app is developed, and accepted into Debian. Debian developers (DDs) make Debian-specific improvements via Debian patches and release a Debian package that then gets installed on Debian end-machines via apt[-get|itude]. At this point, the Debian package (upstream version plus Debian patches) and the upstream may differ significantly. The DD (or other) who made improvements may also get them incorporated into the upstream package via upstream-maintainer connections, which then results in a new upstream version that then gets incorporated into Debian, which can then be released without having to add those previous Debian-specific patches. So, in theory, If I "apt source PACKAGE" or "git clone PACKAGE", I'll get the same base source code, except that as part of the "apt source PACKAGE" route, the Debian-specific patches are applied on-the-fly, during the download/install, so that when I, the end user, look at the two sources, the sources may be different. If the "apt source PACKAGE" method did not apply the patches on-the-fly as part of its routine, I'd see no difference between the two sources (assuming nothing had changed upstream in the meanwhile). If I'm understanding correctly, yea! Thanks, all! -- Kent West<")))>< Westing Peacefully - http://kentwest.blogspot.com -- Kent West<")))>< Westing Peacefully - http://kentwest.blogspot.com
Fwd: Q. about Tinkering with Debian Source Code
Oops, went to Stefan instead of list; sorry. (Google Mail is so ... broken, in some ways.) -- Forwarded message - On Mon, Mar 25, 2019 at 3:50 PM Stefan Monnier wrote: > > When I use "apt source sl" (from sid, into its own directory) and compare > > that tree (?) with what I get if I download via what that suggests (git > > clone https://salsa.debian.org/debian/sl.git) (into its own directory), > I > > notice that the Makefile in the Debian version is slightly > > more complex. > > I believe the difference should be that "apt source sl" will have > applied the patches that you can find in the `debian/patches` > subdirectory of the https://salsa.debian.org/debian/sl.git version. > > > Stefan > > Thank you. I'm not quite far enough along to know exactly what to do with this information, but it got me past a conceptual bump; it helps me to make sense of the bigger picture, and I should now be able to plod a bit further. -- Kent West<")))>< Westing Peacefully - http://kentwest.blogspot.com -- Kent West<")))>< Westing Peacefully - http://kentwest.blogspot.com
Re: Q. about Tinkering with Debian Source Code
Hi, Disclaimer: I am not a Debian member and only prepare the Debian packages of my own upstream project. So i'm just one or two steps ahead of you. Kent West wrote: > Should I consider the Debian download as the official source, of the Git > version? s/of/or/ ? It depends on where you plan to submit your changes. If you want to help developing the upstream software project, then work on a git clone and ask the upstream project people for advise how to contribute. If you want to improve the Debian package, then work on the source tarball http://deb.debian.org/debian/pool/main/s/sl/sl_5.02.orig.tar.gz and the Debian addons http://deb.debian.org/debian/pool/main/s/sl/sl_5.02-1.debian.tar.xz Check the Debian package repository for pending patches which are not yet part of an uploaded package version: https://salsa.debian.org/debian/sl https://salsa.debian.org/debian/sl/commits/master A good collection of links for a package is provided by the package tracker: https://tracker.debian.org/pkg/sl In any case you should try to find out what the Debian patches do: https://sources.debian.org/src/sl/5.02-1/debian/patches/ (also in sl_5.02-1.debian.tar.xz and in salsa.debian.org as .debian/patches) In the end you will need a sponsor for getting the new package version into Debian. Read https://mentors.debian.net/intro-maintainers Begin to read https://www.debian.org/doc/manuals/maint-guide/ > If I start > with the Git version, and it were to get accepting back into Debian, > wouldn't that erase all the extra stuff that has been added to the Debian > version that is not in the Git version (unless I find it all and re-include > it)? That's why the debian stuff is separate from the original stuff. (But the original stuff is often a bit outdated, compared to the original project's git.) Of course, a new upstream release needs to be checked whether the patches still make sense and apply properly. > If I start in the Debian version and it gets accepted back into Debian, > wouldn't that make the Git version just that much more irrelevant? Normally you are supposed to discuss your findings and code changes with upstream, so that your patches become obsolete with the next upstream release. Up to then, they could fix bugs, implement new features in advance, improve documentation, or make the package more feasable for Debian. Sometimes it might be necessary to permanently deviate from upstream decisions by permanent patches. But that should only be the last resort if upstream cannot or does not want to follow your well motivated proposals. Have a nice day :) Thomas
Re: Q. about Tinkering with Debian Source Code
On Mon, Mar 25, 2019 at 04:49:15PM -0400, Stefan Monnier wrote: > > When I use "apt source sl" (from sid, into its own directory) and compare > > that tree (?) with what I get if I download via what that suggests (git > > clone https://salsa.debian.org/debian/sl.git) (into its own directory), I > > notice that the Makefile in the Debian version is slightly > > more complex. > > I believe the difference should be that "apt source sl" will have > applied the patches that you can find in the `debian/patches` > subdirectory of the https://salsa.debian.org/debian/sl.git version. > Apart from that, depending on how active development on a given package is, the code checked out by debcheckout may differ from what is currently in Debian. Some reasons for this might include: - The maintainer has made new commits that have not yet been uploaded to unstable - You are running stable and debcheckout gets an old repository URL that is no longer in use (in which case you get outdated code) Regards, -Roberto -- Roberto C. Sánchez
Re: Q. about Tinkering with Debian Source Code
> When I use "apt source sl" (from sid, into its own directory) and compare > that tree (?) with what I get if I download via what that suggests (git > clone https://salsa.debian.org/debian/sl.git) (into its own directory), I > notice that the Makefile in the Debian version is slightly > more complex. I believe the difference should be that "apt source sl" will have applied the patches that you can find in the `debian/patches` subdirectory of the https://salsa.debian.org/debian/sl.git version. Stefan
Q. about Tinkering with Debian Source Code
Hi! I'm trying to dip my toe in the waters of editing the source code of Debian packages, and I've started with the simplest, most innocuous program I could think of - sl (the ASCII train that goes by on the screen when you mistype "ls" as "sl). When I use "apt source sl" (from sid, into its own directory) and compare that tree (?) with what I get if I download via what that suggests (git clone https://salsa.debian.org/debian/sl.git) (into its own directory), I notice that the Makefile in the Debian version is slightly more complex. I also notice some extra code in the Debian's "sl.c" file which is not in the Git version's, which indicates to me that the Debian version has updates that are not in the "newest" version on the Git repository. Should I consider the Debian download as the official source, of the Git version? If I were to make changes to feed back to the project, would I want to make the changes to the Debian version or the Git version? Has the Debian version essentially forked, making the Git version irrelevant? If I start with the Git version, and it were to get accepting back into Debian, wouldn't that erase all the extra stuff that has been added to the Debian version that is not in the Git version (unless I find it all and re-include it)? If I start in the Debian version and it gets accepted back into Debian, wouldn't that make the Git version just that much more irrelevant? I'm not even sure my questions make sense; I'm just trying to wrap my brain around the basic process. Thanks! -- Kent West<")))>< Westing Peacefully - http://kentwest.blogspot.com
