[Dev] about new packagers and personal repos

Joshua Ismael Haase Hernandez hahj87 at gmail.com
Thu Feb 23 15:57:15 GMT 2012


On Thu, 23 Feb 2012 09:07:29 +0100, gnu.tek at gmx.com (=?utf-8?Q?Aur=C3=A9lien?=) wrote:
> Nicolás Reynolds <fauno at kiwwwi.com.ar> writes:
> 
> > On Mon, 20 Feb 2012 00:49:09 -0300, Nicolás Reynolds <fauno at kiwwwi.com.ar> wrote:
> >> since i've been receiving a few queries about becoming a parabola
> >> packager and having access to a personal repo (the [~people] kind of
> >> repos), i'd like us to discuss a few guidelines so everything is clear
> >> :)
> >> 
> >> situation so far:
> >> 
> >> to be a packager you need a pair of ssh and gpg keys. ssh is needed to
> >> access the repo server and to upload packages, and the gpg key is
> >> required for signing them.
> >> 
> >> db-update refuses to release packages if they're unsigned, but it
> >> doesn't perform validity checks. this is pretty simple to implement so
> >> it may be done in a few days if no one beats me to it. make sure to post
> >> your gpg key to a keyserver (any but pgp.mit.edu).
> >> 
> >> we have been giving repo access to people we know from the irc channel.
> >> 
> >> for a [repo] to show on parabolaweb an admin (currently encyclomundi and
> >> i, iirc) has to create a new repo on the django admin page. it also has
> >> to be *commited* to the main dbscripts.git repo after including it on
> >> the config file, so it can be pulled on the web server. from then on, a
> >> cronjob takes care of including new packages to parabolaweb database.
> >> 
> >> / end of situation
> >> 
> >> so what do you think? :)

I think we need a document describing package flow, so It does not work
as a blackbox. Also, writing guidelines seems right.

> > related:
> >
> > we've been discussing about how to decentralize a PUR and using git
> > repos (or any dvcs) for that seems to be the right way.
> >
> > one of the ideas is to have a git repo for each package (xihh would like
> > this) and putting them as git submodules of a personal repo, in a way
> > that you could, for instance:

+1

> > git clone git://fauno-machine/fauno
> >
> > and have every package maintained by me, or from your repo:
> >
> > git clone git://fauno-machine/fauno/a-package
> > git submodule add a-package
> >
> > and import a single package to your repo. common tasks can be put on
> > libretools scripts. arch packages can be retrieved from their branches,
> > though the whole repo is heavy.
> >
> > in the next days i'll be writing an article about git hosting on the
> > wiki for starters :D 
> >
> >
> 
> Hi,
> 
> The idea of a full wiki help page on the subject seems nice.
> 
> for the place of the git, it can be a good experience to know 'how make
> your own git' but for a 24/24 7/7 distro need ... maybe it is not the
> best way to use.

I think there should be a superrepo on the server containing all
packages in a submodule and each dev can have it's maintained packages
on his/her machine as a personal repo.

> Or maybe if it's possible a sort of decentralization recentralized
> ... each builder make it's own git as you suggest, but the server is
> able to a form of rsyncing all git in one ... like that all git are
> always available to all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120223/40f6cb25/attachment.sig>


More information about the Dev mailing list