Re: Re: RE:RE:Ad-hoc survey of existing Debian git integration tools
picca writes ("Re: Re: RE:RE:Ad-hoc survey of existing Debian git integration tools"):
> It seems to me but I can be wrong that the dgit informations stored
> under .git/dgit are sort of meta data which point to git ref
> corresponding to packages uploaded into Debian.
Don't look in .git/dgit. There's not really much of interest there.
It's mostly used for scratch space. dgit does squirrel away a
hardlink to the .orig.tar.gz but, really, that's not metadata; just a
convenience hardlink in case the link in the .. gets removed.
> Is it possible for dgit to allow pushing to another derivativ
> instead of Debian from the same repository ?
Yes. You can use dgit with multiple distros from the same tree.
However, this is mostly theoretical since currently dgit can only push
to Debian. (There is read only support for Ubuntu but read only dgit
support not hugely uninteresting.)
> > Either the file (`configure', say) is part of your source code, in
> > which case it should be in the source package and in the git
> > repository; or it is not, in which case it should be absent from both.
>
> ok, so you just say that the git repository used by dgit-repo
> contain all the files that we obtain using dpkg-source to extract a
> usual debian package.
Yes, precisely. The only differences are: extracting the package does
not (well, should not) produce a .git directory, but of course a dgit
clone does; and extracting the package produces (sometimes) a .pc
directory, which the dgit git tree does not contain.
> We should call this an integration branch right ?
The usual terminology seems to be `packaging branch' AFAICT.
Personally I don't mind what we call it.
> In fact I try to understand how we should use dgit at work in order
> to let developpers do the integration work by themself.
Right.
> We want to put the debian packaging in the upstream git repository
> and generate and push directly a package from this repository to
> either a local mini-build (PPA) or the Debian archive.
That seems possible. I don't know why your local area would need to
have source packages - personally I think source packages are a pain.
You could use _only_ the git trees.
For the Debian archive, you could indeed push directly from your own
integration branch (as you call it) to Debian. (There are
complications if you use source format `3.0 (quilt)'.)
> > dgit should propose a sort of PR (via email) in order for the
> > upstream to propose the integration of its prepared package into the
> > repository. something which is done for now via mentors, maybe
>
> > I don't understand.
>
> I was thinking that an upstream should have work on his own PPA
> managed with dgit or new ppa tool, prepare internally a package then
> request for sponsoring this kind of tool should propose a sort of PR
> generator which should make it trivil to create a RFS RFS and send
> the email with all the informations necessary for a DD to review the
> code and uploading with just a dgit push.
Right. This seems like a tool that could exist.
> The way dgit get the proposed pacakge is indeed not clear :)
In order to do a dgit push, the sponsor would need:
1. The git branch. This can be stored on and fetched from any
suitable git server.
2. Any orig tarballs required. If the RFS is for an update of an
existing package, and does not involve a new upstream version,
the sponsor's own `dgit fetch' will acquire the existing orig
tarballs from the archive, so nothing is needed for this.
`dgit fetch' already understands the need for these two paths, so is
an obvious place to implement the client end. But there needs to be a
server end too.
> Did we had some document or preliminary tought about how to
> integrate the packaging into uptream. something we should let them
> tought that the debian packaging is not something that difficult and
> can be part of their developpement effort.
Debian doesn't seem to have a settled view on this question.
Many Debian maintainers seem to feel that upstream's attempts at
Debian packaging are often poor, and just get in the way.
Historically finding debian/ directories in upstream tarballs has
caused trouble, because Debian's source package formats are unable to
represent certain semantically important kinds of changes that a
Debian maintainer is likely to want to make to a debian/ they find in
an upstream package. In more recent source formats, the orig
tarball's debian/ directory is entirely discarded and replaced so this
problem doesn't arise.
Ian.
Reply to: