X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit.1;h=7e74d5b77f62fdfc2ad5782c3973e8b9b4907c62;hp=c261300f555bd92a3a5c53184edd66ed9a7f28bb;hb=d198bbd72d591b6deba779a8d24cf9bc9ae80894;hpb=6e24ac7bb85e30df00b3d14853b049e3f06b6dec diff --git a/dgit.1 b/dgit.1 index c261300f..7e74d5b7 100644 --- a/dgit.1 +++ b/dgit.1 @@ -361,13 +361,14 @@ filename suggests it is for the right package and version - or, if there is a _multi.changes file, dgit uses that. .TP .BI --existing-package= package -dgit push needs to canonicalise the suite name. But currently -there is no way to ask the archive to do this without knowing the +dgit push needs to canonicalise the suite name. Sometimes, dgit +lacks a way to ask the archive to do this without knowing the name of an existing package. Without --new we can just use the package we are trying to push. But with --new that will not work, so we guess .B dpkg -or use the value of this option. +or use the value of this option. This option is not needed with the +default mechanisms for accessing the archive. .TP .BR -h | --help Print a usage summary. @@ -481,10 +482,11 @@ remote. This refers to the well-known dgit-repos location (currently, the dgit-repos project on Alioth). dgit fetch updates the remote tracking branch for dgit/suite. -dgit does not (currently) represent the orig tarball(s) in git; nor -does it represent the patch statck of a `3.0 (quilt)' package. The -orig tarballs are downloaded and kept in the parent directory, as with -a traditional (non-gitish) dpkg-source workflow. +dgit does not (currently) represent the orig tarball(s) in git. The +orig tarballs are downloaded (by dgit clone) into the parent +directory, as with a traditional (non-gitish) dpkg-source workflow. +You need to retain these tarballs in the parent directory for dgit +build and dgit push. To a user looking at the archive, changes pushed using dgit look like changes made in an NMU: in a `3.0 (quilt)' package the delta from the @@ -612,11 +614,11 @@ on the dgit command line. .TP .BI dgit-distro. distro .archive-query-default-component .TP -.BI dgit-distro. distro .sshdakls-user +.BI dgit-distro. distro .sshpsql-user .TP -.BI dgit-distro. distro .sshdakls-host +.BI dgit-distro. distro .sshpsql-host .TP -.BI dgit-distro. distro .sshdakls-dir +.BI dgit-distro. distro .sshpsql-dbname .TP .BI dgit-distro. distro .ssh .TP @@ -645,20 +647,13 @@ We should be using some kind of vhost/vpath setup for the git repos on alioth, so that they can be moved later if and when this turns out to be a good idea. -Debian Policy needs to be updated to describe the new Dgit .dsc -field (and to specify that it is an RC bug for that field to refer -to an unavailable commit). - -The method of canonicalising suite names is bizarre. See the -.B --existing-package -option for one of the implications. - dgit push should perhaps do `git push origin', or something similar, by default. Debian does not have a working rmadison server, so to find out what version of a package is in the archive, or to canonicalise suite -names, we ssh directly into the ftpmaster server. +names, we ssh directly into the ftpmaster server and run psql there to +access the database. The mechanism for checking for and creating per-package repos on alioth is a hideous bodge. One consequence is that dgit currently @@ -698,16 +693,11 @@ There should be an option which arranges for the `3.0 (quilt)' autocommit to not appear on your HEAD, but instead only in the remote tracking suite branch. -There should at the very least be some advice in the manpage about how -to use dgit when the signing key is not available on the same machine -as the build host. - The option parser requires values to be cuddled to the option name. -dgit assumes knowledge of the archive layout. There appears to be no -sane way to find the path in the archive pool of the .dsc for a -particular suite. I'm assured that the archive layout is a -`well known algorithm' by now. +dgit assumes knowledge of the archive database. (The information dgit +needs is not currently available via any public online service with a +well-defined interface, let alone a secure one.) --dry-run does not always work properly, as not doing some of the git fetches may result in subsequent actions being different. Doing a