[repoman] conversation starter

[Essien Ita Essien]

Paul Mattal wrote:
> So things have gotten off to a slow start, but they're speeding up.
> 
> Have a look at the very first iteration of the repoman homepage:
> 
>    http://repoman.mattal.com

hey... looking good :)
> 
> <snip>

> One thing I've been thinking about is whether our system can be entirely 
> SCM agnostic, or at least designed in a way so that others could be used.

This is a very noble quest :) and infact I believe it is the best 
approach. Low barrier to entry and no time wasting over best [D]SCM 
talks (though i'll miss the nice flamings on [D]SCMs we _could_ have 
had, if you'd allowed to us to argue about this :P)

> 
> My idea was that in essence a repository can be completely specified as 
> a set of (pkgname, PKGBUILD-dir, revision) triplets where no two package 
> names are the same within a single repository. If you define some "UPL" 
> or Uniform Package Locator comprised of essentially a name + SCM URL + 
> revision, and you allow UPLs to support many different kinds of SCMs, 
> you can end up expressing a repository as simply as:
> 
> mypackage:svn://foo.bar.baz/mypackage:23785
> anotherpackage:cvs://arf.bar.boo/some/directory/anotherpackage:1.1.3
> package:hg://some.other.site/one/other/package:<revisionid>
> yapkg:git://...

I can't help thinking of the actual implementation at this stage. (my 
coding arm is itching :) ). How will the folder structure look like, and 
the SCM policy be? Do we maintain each package as its own REPO? Or all 
of them as folders/modules under one repo?

Normally SVN and CVS have a repo root and then modules, and for DSCMs 
like hg, you can usually only clone/pull the root. So I would guess that 
we'd have repo's arranged like:

/reporoot/
	-package1
		PKGBUILD
		...
	-package2
		PKGBUILD
		...

Then for svn and cvs, svn://foo.bar.baz/mypackage would be come svn co 
foo.bar.baz mypackage.

This would be problematic for hg (and git?), since we'd have to 
clone(pull), the _entire_ repo first before now obtaining the *folder* 
we're looking for. How also, would you be able to grab at the 
<revisionid>s, being the tags are applied to the REPO not the 
modules/folders in the REPO.

So it looks like package per REPO is the sanest way to do this, but 
won't that be a lorry load of REPOs to manage?

Hope that mumbo jumbo makes some sense.
> 
> The nice part is that this also alleviates the need for any sort of flag 
> in SCM to tell you that a package is "current" or "testing" or whatever. 
> The place where such a "tag" really belongs is in the specification for 
> the repository, not the package.

makes sense.

> 
> What do people think about this?
> 
> You can then build a repository from just such a list, or export it to 
> such a list. It's tempting to point to a higher level directory and get 
> a whole bunch of packages.. but then remember you can't have a separate 
> *version* specified for each package.
> 
> Of course, you would have devtools and such to do the hard work for you. 
> This is just how we would be thinking about things behind the scenes.
> 
> - P
> 
> _______________________________________________
> repoman mailing list
> repoman at archlinux.org
> http://archlinux.org/mailman/listinfo/repoman
>