"Daniel Clark/Cambridge/IBM" <dan...@us...> writes:
> I've been looking for a generalized ports package that would integrate well
> with modules, and MPKG looks like it fills that need. I have a few initial
> questions/comments about MPKG.
>
> CVS:
> I had this error when trying to do a CVS checkout with
> CVSROOT=/afs/e.kth.se/src/SourceRepository :
>
> $ cvs co mpkg
> cvs checkout: Updating mpkg
> cvs checkout: failed to create lock directory for
> `/afs/e.kth.se/src/SourceRepository/mpkg'
> (/afs/e.kth.se/src/SourceRepository/mpkg/#cvs.lock): Permission denied
> cvs checkout: failed to obtain dir lock in repository
> `/afs/e.kth.se/src/SourceRepository/mpkg'
> cvs [checkout aborted]: read lock failed - giving up
try "cvs -R co mpkg" if you have the cvs-nolock-patch.
> It took me a little while to find
> http://www.stacken.kth.se/projekt/arla/#cvs_tree and then go and find the
> source to CVS 1.10 (http://ftp.cvshome.org/cvs-1.10/cvs-1.10.tar.gz), apply
> the cvs-nolock.diff patch, and compile. There may be a race condition
> caused by this patch - (a) reader looks for lock and doesn't see it; (b)
> writer creates lock, and starts writing file; (c) reader opens and reads
> partially written file. I don't know enough C to tell if the patch contains
> countermeaures against this possible problem, but as of the latest CVS
> version (1.11.2) it looks like the behaviour of requiring read-only users
> to be able to write to CVS lock files in the repository or the LockDir
> specified in CVSROOT/config still exists. So if it isn't too much trouble
> it would be useful if anoncvs access could be provided via pserver or the
> ssh method arla seems to use (I tried using anoncvs.stacken.kth.se but mpkg
> doesn't seem to be one of the cvs modules that is rsynced to that server)
mpkg is not a stacken-project, mpkg i developed by the Sysadmin team of the
Departmant of Eletrics at KTH. We compile almost all software with mpkg for
all our plattforms ( Tru64, Linux, Solaris ).
We should really fix a pserver, you a re right, we should also fix some
public mailinglist, the intrest in mpkg is a little bit bigger than we
thought it would be, which of course make us very happy!
> Collaboration:
> In general do you view MPKG as an internal project that others may find
> useful to look at and possibly branch for their own environments
There are 2 trees, one "mpkg" and one "mpkg-configuration", the idea is to
keep our sitespecific stuff in mpkg-configuration.
>, or are
> you interested in accepting / managing contributed ports along the lines of
> the *BSD model?
This would be great, YES!
We would be very happy to see more people writing makefiles.
In the meanwhile just send your patches via mail, in the long run we may
give commit-rights to other serios sites working heavily with mpkg.
/Jimmy
|