[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] General Resolution to deploy tag2upload



Matthias Urlichs writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Another way of doing this would be to teach t2u to simply push the tag 
> to an append-only git store.

tag2upload already does precisely that.  (dgit does this too.)

> Then teach the builders that instead of their equivalent of "apt-get
> source" they should fetch this tag from our git store and run dgit
> (and then push the legacy source tarballs) themselves.

Right now that wouldn't work right because only uploads done with
tag2upload (or dgit) are visible in the dgit-repos git repository.

This is why `dgit clone` must look at the ftpmaster API server, and
archive mirrors, as well as the git repository, and must sometimes
import source packages.  So, for example, Raspbian, who are ingesting
Debian as git branches, must use `dgit fetch` and can't use
`git fetch`.

One thing I'd like to do is make dgit unnecessary on the client side,
too, and just let people use "git clone/fetch".  I think supporting
that is quite a way off.

But an obvious next step is:

Have a robot convert non-t2u/dgit uploads to git, and push the results
to dgit-repos.  That's not practical right now for a number of
reasons, inclidng that it wouild dramatically and suddenly increase
the size of dgit-repos for not much benefit.  If tag2upload becomes
widely used that calculus would change.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.


Reply to: