pkgsrc-Users archive

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

Re: Moving pkgsrc-wip away from SourceForge

Am Mon, 6 Jul 2015 15:07:13 +0530
schrieb Mayuresh <>:

> I believe individual contributors (about whose ease of contribution the
> discussion is going on) are not required to deal with such large size.

Well, you got some packages that need to be updated in a group. But,
generally, you say that people interested in changing something only
work on a package directory and it would be a waste to have to download
any repository data before it's needed?

I see the point for CVS that it is very lean on the working copy, as it
only stores some metadata. The use case of the simple tarball having
links to the CVS server without noticeable additional payload is an
interesting feature, when I think of it. When then, you only do cvs
commands on individual packages, I can begin to understand why CVS
still works for pkgsrc.

Current candidates on revision control have either "pristine"
reference files or the history contained in a working copy, which is
wasted on the everyday user who doesn't change anything. I see a use
case there for Subversion to add a mode where it doesn't include the
pristine files in .svn and fetches that information from the server on
demand only.

> I do not know the nature of files in packaging spec you describe, but in
> pkgsrc, it's typically Makefile, distinfo, PLIST and Descr and in some
> cases patches. With a typical contributor focusing on 1 package at a time,
> I really doubt whether it compares with the scale you are talking about.

Oh, it's very similar. In SMGL it's not written as Makefiles, but in
bash scripts setting variables and calling Bash functions. You got
minimum two files per package, but it can also be more if you need to
override defaults or include patches. The files are all rather small
plain text, like in pkgsrc. Other source based distros try to keep
things collected in one file per package, plus patches.

> I use both CVS and git, though not so proficient with the latter. So far
> in my usage, which is for closely knit groups, with a centralized
> development model, I always found CVS to be simpler.

I agree, given you replace CVS with SVN, which is designed to carry on
the user interface from CVS and extend it. Apart from the minimal
working copy argument above, I cannot fathom a reason for, as a user (and
not admin complaining about svn needing heretic libraries like apr;-),
continue to use CVS instead.

But if it works, it works. The most basic commands are the same with
SVN and CVS. I never used tags or branches in CVS and I hope I won't
have to.

Alrighty then,


Dr. Thomas Orgis
Universität Hamburg
RRZ / Zentrale Dienste / HPC
Schlüterstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Home | Main Index | Thread Index | Old Index