Q. about Tinkering with Debian Source Code

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Q. about Tinkering with Debian Source Code

Kent West
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
Reply | Threaded
Open this post in threaded view
|

Re: Q. about Tinkering with Debian Source Code

Stefan Monnier
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Q. about Tinkering with Debian Source Code

Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Q. about Tinkering with Debian Source Code

Thomas Schmitt
In reply to this post by Kent West
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

Reply | Threaded
Open this post in threaded view
|

Fwd: Q. about Tinkering with Debian Source Code

Kent West
In reply to this post by Stefan Monnier
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Fwd: Q. about Tinkering with Debian Source Code

Kent West
In reply to this post by Thomas Schmitt
Oops; when to Thomas instead of list; sorry. (Gmail, ugh!)

---------- Forwarded message ---------



On Tue, Mar 26, 2019 at 3:23 AM Thomas Schmitt <[hidden email]> 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.

<snip>

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Q. about Tinkering with Debian Source Code

Kent West

On Tue, Mar 26, 2019 at 8:17 AM Kent West <[hidden email]> 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 <[hidden email]> 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