[repoman] conversation starter

[Dan McGee]

On 7/1/07, Essien Ita Essien <me at essienitaessien.com> wrote:
> 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)

I want to do this as well. Modular is hard at first, but nice. It
would be great to be able to drop in any VCS with minimal changes
needed. I personally am a GIT fan now, but I know others are not as
fond of it, and some still like the centralized feeling of SVN.

> > 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 wish we could abstract a bit more from the VCS-specific revision
numbers. That seems clunky to me.

I'm also not sure on how multiple repositories would exist in this
format, but I think that is more on me than you. Can you give two
example UPLs for what we currently call current and extra packages (of
the same package)?

Finally, I think we should all get on the same page when referring to
repositories, packages, tags, etc. If anyone wants to define some of
these key terms, I think that would be smart.

> 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.

There is no reason that different SCMs couldn't have different default layouts.

> 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.

True about pulling the whole repo, but I'm not quire sure what 'tag'
means in this context. I think we are trying to get away from that
clunky system, and have seperate repositories that are for testing,
etc. However, this makes it harder to port to and from testing...

> 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.

+1

> > 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.

I think as long as there is a frontend tool that is managing the hard
work, and is easy and powerful enough to use, we shouldn't have to
worry about people wanting to dip behind the scenes and do their own
dirty work.

> > 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

For Paul's SVN export concern:

That is one way to think of it, but if we build our operations to be
agnostic enough, there is nothing telling us we can't just check out
the full subversion repository. We will need to pull full repositories
for GIT/HG/most distributed tools anyway.

-Dan