Christian Perrier: 10 years being Debian Developer - part 4: NM process
So, this story begins in January 2001, when I applied in the Debian New
Maintainer Process.
I wanted to maintain Geneweb, which I was using to publish my
genealogy research results. And I wanted to keep it up-to-date while
upstream was doing a quite fast development.
Moreover, I quickly noticed that Geneweb had big trouble in respecting
the way data is organized on a Debian system, and respect the FHS. How
to have weveral users able to publish their data on the same server
without compromizing the overall system security, etc.
Upstream development didn't really care about that. Daniel de
Rauglaudre is an excellent genealogist and developer but he was not
interested in making Geneweb clean "the Debian way". For instance, at
that time, it wasn't easy to setup a server, where genealogy databases
could be published without having to manually launch a daemon in user
mode at each reboot.
Arranging this was indeed my first contribution. I contributed a few
patches to make it easier to turn Geneweb into something
FHS-compliant...and I developed init scripts and an organization
allowing one to have shared databases after system reboots.
That was rapidly a great introduction to Debian maintainer scripts and
even security-related challenges. And all this....because I needed it.
Basically, in 2001, the geneweb package adopted the organization it still has in Debian
and Ubuntu, 10 years later:
- daemon optionnally launched at boot time, listening on a configurable port
- daemon running with an unprivileged account
- local group of users allowed to "publish" their data by putting files in /var/lib/geneweb (should now be moved to /srv, I guess)
- related maintenance of this with debconf (including keeping local modifications made *out* of debconf, which is sometimes neglected by maintainers)
- Firstly, can you explain the key points of the Social Contract and DFSG?
- Donald Knuth, author of TeX, insists that no-one has the right to modify the source code of TeX, and that any changes must be made using "change files" (a sort of patch file). Furthermore, any modification of TeX which produces something which fails the "trip test" (a regression test suite) may not be called TeX. So how come TeX (in the guise of tetex-*) is in main?
- What is Debian's (current) approach to non-free software? Why?
- Debian was offered a Debian-specific license to package a certain piece of software (I forget which). Would we put it in main?
- Q: Do you know (and can you explain) the difference between free speech and free beer? Is Debian mainly about free speech or free beer? My answer: Free speech means that one is able to say what one wants, without any constraint. No one can tell you what you should say. Mozilla is free software. A free beer, on the other hand, is a beer that you don't be charged for. You may drink a free beer but maybe cannot be free to choose the beer you want to drink...:-). Internet Explorer is a free beer. By chance, we french-speaking people have two different words for this (libre and gratuit). Some people have even adopted "libre software " for being used instead of "free software".
- Q: The e-mail client pine is in non-free. Can you tell me the difference between main, contrib and non-free? My answer (typos and horrible English not corrected...): Packages in main are OK with Debian Free Software Guidelines (which defin what is considered "free" by Debian) and all other requirements of the Debian Policy. Packages in contrib are OK witgh DFSG bu may break some other constraints. For instance, they may be wrappers for non-free packages (the old netscape wrappers were good examples. The setiathome package is also another example as it requires the download of the setiathome client which is not free, because source code is not available). Very buggy packages may also be placed into contrib instead of main (a QA requirement). Pakages in non-free are not conform to DFSG. Simply speaking they are not "free software" as defined by DFSG. Some of them because their licence prohibits redistribution, or redistribution of derived work (the french package of Bernard Gaulle fot Latex could fall there).
- Q: Do you agree to uphold the Social Contract and the DFSG? Answer: Yes I do (wow! I'm back 16 years down to my wedding day...:-)) (Doh, already kidding with fellow DDs)
- Q: If you are accepted as a Debian developer, you will get accounts on the Debian machines. Have you read the Debian Machine Usage Policies (DMUP) at http://www.debian.org/devel/dmup ? Do you accept them? My answer: I did read the DMUP and I fully accept them.
- Q: What are Non-Maintainer Uploads (NMUs) and when would you do an NMU? Answer: This is an update for a package which is done by someone who is *not* the official package maintainer (I guess I give the correct english definition : I read the translated dev. reference....). First of all, a NMU should be done after trying to get in contact with the official package maintainer. I don't know if this is the awaited answer, but this point looks important to me. This is the only way for verifying that (s)he is not working on the same problem. NMU's are the most welcome during freeze phases when they correct bugs rated "severe" of higher. They are also welcome when they come from Debian Security Manager(s) for correcting security-related bugs. Another NMU source are those which are needed for ports to work. As a recent, and probably not very experienced package manager, I would probably be very prident with NMU's anyway...:-)
- Q: Tell me 3 different methods to close a bug in the BTS. Answer:
Well, If I have properly understood Dev. Reference, there are two
recommended methods and a third which is discouraged :
- properly use the debian/changelog file (by adding "Closes: Bug#xxxxx" statements in it). The bug will automagically be closed by the archive maintenance software
- by mail by sending the .changes file to xxxxx-done@bugs.debian.org, xxxxx being the bug number
- by sending a "close" command to control@bugs.debian.org
- Q: What would you do if a bug was reported against your package and you are not able to fix it yourself? Answer: First, I would double check with upstream author(s) if this cannot be fixed by him/her/them.... Then, I would probably ask for help and/or advice in debian-qa if the bug is critical, grave or serious. If it is normal, I would ask on debian-devel or maybe think more about possible solutions.... If the bug still cannot be fixed and is "severe" or higher, I would either consider orphaning it (not being able to fix it may mean that I do not have the skills for maintaining it properly) or having it adopted by someone else. I don't think there is a unique answer there. The key point for me is certainly "ask for help in debian-qa". (OK, not the best answer ever...)
- Q: You've just heard about this great program and would like to package > it, what would you do? Answer: First, check on the WNPP page. The purpose here is avoiding having two people working on the same package. Then, assuming no on,e works on it, open a bug against wnpp speudo-package with a copy to debian-devel. The "bug" should include a short description of the package and what I intend to do for packaging. The URL for downloading sources for the program should be given. The subject of the bug report is normalized. The bug report should be of the "wishlist" class. When the new package is ready and uploaded for the first time, it should include the appropriate statement for closing the wnpp bug.
- Q: Do you know what 'lintian' is? Why is it useful? Answer: It is a set of tools for making automatic checks of packages. It may detect some bugs, common errors, Debian Policy violations and so on. This is a very useful tools for polishing packages. For instance, in my "geneweb" unofficial package, the last remaining lintian report is about the creation of a /var/geneweb directory which violates Debian Policy.
- Q: What does version 3.4-2.1 mean? What Debian control file would you put this in? (Hint: NMU). Answer: This is the Debian package of version 3.4 of program "foo". The current package version in the distribution was -2 and someone made a NMU of this package. This would be put in debian/changelog
- Q: You have a package in contrib, why would it have to go there? What could you do (in theory at least) to get it into main? Answer: The package in consistent with DFSG but other constraints are not respected. The most probable reason is being dependent of "non-free" packages (there may be other reasons but none comes to my mind at this time....). In that case, I should try to make it independent of these packages. For instance, trying to replace a "Depends: netscape-base" line by a "Depends: www-browser" line...if it may be done, of course!
- Q: If you had a file in your package which usualy gets changed by a user for local settings, how doyou make sure your next version of the package doesn't overwrite it? Answer: By putting its name into the debian/conffiles line. By the way, I guess you're meaning "changed by a local system administrator for local settings" here, don't you? (hey, answering a question with another one, good trick, man...)
- Q: What would you do if you wanted to retire from the project and let other developers maintainer your packages? Answer: The correct term is "orphan" the package. Make a bug report against wnpp (with a normalised subject starting with O, see Dev. Ref). The bug severity is "normal". If this is an important package for the distribution, the bug should be of "important" severity and the bug report should have a subject beginning with RFA (Request For Azdoption). In that case, an announce in debian-devel is also asked. In both cases, a new package should be uploaded with Debian QA Group as maintainer.