Thank you very much.
Thanks everybody for coming,…
If you are packaging software and you want me to work on with you,
this is how you can do that.
It is a very self-??? talk:
I just want to explain some of the things that I like,
some practice that I prefer about Debian packaging,
and I don't pretend this is any sort of official,
permanent or final thing.
I just wanted to share some ideas that I have about the way that I work with
packages, in the hope that maybe, hmm, for two hopes:
One is that I hope that I can show you something that you have not heard of,
or maybe you were doing differently,
or maybe you think it is the right think to do and it is just nice to see somebody
somebody else doing it.
My second hope is that you can tell me what I am doing wrong,
and you can help me learn and improve on my own packaging techniques.
If you see something that I am proposing up here,
and you think there is a problem with it, I would like to hear about it too.
I just want to see more of the culture within Debian,
of people who are doing packaging, explaining what they are doing,
and so I thought I would just step up and explain:
"Here is some of the practice that I do",
In the hope that other people will do the same and explain what they are doing,
and maybe they can learn from me and I can learn from them.
Without much further ????, I am just going to dive into it.
If you have questions, I am perfectly happy to be interrupted,
we have some folks with walking mics in the crowd:
you can just raise your hand.
I you have got a question or an interruption or whatever,
that is fine.
I ??? I got the whole 15 minutes, I think there are 20 minutes,
I ??? the whole time, so there will be also time for questions at the end
if you prefer.
But I do not mind being interrupted.
So, this is all on this web page here,
you could probably skip this talk and go read the web page,
but then you would not have the nice ??? actions,
and it is easier to tell me that I am wrong in person,
so I would like to have that happen.
I put this up on the Debian wiki,
because I want anyone to be able to find it.
If you thing you have got some good ideas, you should put it on the Debian Wiki too:
other people can take advantage of the ideas that you have got.
First baseline is: I really like revision control.
And I know that it makes me a certain flavor on nerd,
but when we are working with things that are as complicated as software packages,
hmmm, I think a lot of people don't get that in Debian we are not just working on
one software package:
you are actually probably, if you are doing a responsibly work,
on at least two software packages, and maybe 5.
So you have got the version that is unstable and you have got
the version that you try to maintain for stable as well.
And we are committing to doing maintenance work.
A lot of our work in the project is ??? in nature:
we want to clean up the mess and we want us to stay out of the way and
to make sure things work, functionally,
for people who are relying on the operating system to not get in their way.
So revision control I think is really helpful because it means you can
keep track of what changes you have done on different branches of the project
while you are maintaining both of them.
Basically, ??? require working with the revision system I am comfortable with,
I prefer Git, I am not going to have a religious word about it.
If upstream uses Git, I am even happier, and I try to make my packaging depend on
upstream's revision control.
I like to use 'git-buildpackage', and I like to use it with debhelper.
If you have not tried out 'git-buildpackage',
we are going to have a 'git-buildpackage' skill share session
later on today actually, and I welcome you to come and share your tricks with it,
or learn some tricks from other people.
It is a particular way that you can keep your Debian packaging in a Git repository,
and it helps you to keep track of all of the changes that ave happened within
your packaging and within upstream to make sure you are not accidentally
making other changes.
So it is very easy to go back and review what you have done.
I find that really useful.
I definitely also like to keep upstream's source code in the same revision control
system.
I like to keep the tarballs in the revision control system because it means
that if someone is interested, they can uses a tool called 'debcheckout'.
You can use 'debcheckout' with a name of a package:
you say just "I am really interested in package 'foo',
let me see the source code for that":
debcheckout foo
You get the source code, and you get the source code from a revision control
system that you can now track and you can just propose changes on.
You can also extract the tarball from that revision control system.
'debcheckout' actually works even if you do not have upstream stuff in there,
but I like to keep it all in one revision control system,
it is just easier to find everything when you want.
Some of these things that I prefer have to do with what the upstream software
developer has done, so I am less inclined to try the package an upstream software
project if they just throw tarballs here over the wall to an FTP side
every now and then.
It makes it more difficult for me to know what they are doing,
and why they are doing it.
So i like it, I have already said, when upstream uses Git,
I also like when upstream signs their releases,
and say "hey, this is specific release",
Because that is a signal that I can use, or somebody else that understands the
project: as said "we think that this something that other people can use",
or "this is a particular version we would like other people to test".
There are a lot of other situations where maybe it is not so important.
And having that be cryptographically signed is really useful.