using svn to fetch for ports (yet again!)
Eitan Adler
replace its do-fetch with a svn export of a /specific revision/ of a
remote repo.
I know there have been some attempts at trying this before and from
what I've been reading I addressed some of the major concerns:
1) Past attempts didn't include a basic implementation.
2) Past attempts didn't allow for a specific revision number and thus
possibly causing security issues
3) Subversion does not have to be part of the base system for my patch to work
Allowing the port to fetch from svn is beneficial for a number of
reasons some of which are listed below
1) Many project's only or main means of distribution is svn (I'm
thinking of mplayer)
2) It is easier for the port maintainer to update the port
3) It is easy for a user to quickly switch versions (outside of the
ports system) without the need for lots o knowledge about the ports
system
Some of the problems:
1) Its harder if not impossible for freeBSD to mirror the port's
source (I'm sure I could easily code a svn-to-tarball script but who
knows if the svn build servers want svn)
2) Many users may want the program they are installing but not svn
3) What about SCM's other than svn?
--- bsd.old.port.mk 2009-11-04 19:42:57.000000000 +0200
+++ bsd.port.mk 2009-11-04 19:59:10.000000000 +0200
@@ -1694,6 +1694,10 @@
MANCOMPRESSED?= no
.endif
This is a patch to bsd.port.mk which adds support for SVN_REV and SVN_FETCH
+.if defined(SVN_FETCH)
+FETCH_DEPENDS+= svn:${PORTSDIR}/devel/subversion
+.endif
+
.if defined(PATCHFILES)
.if ${PATCHFILES:M*.zip}x != x
PATCH_DEPENDS+= unzip:${PORTSDIR}/archivers/unzip
@@ -3435,6 +3439,10 @@
.if !target(do-fetch)
do-fetch:
+.if defined(SVN_FETCH)
+ ${MKDIR} ${WRKDIR}
+ svn export -r ${SVN_REV} ${SVN_PATH} ${WRKSRC}
+.else
@${MKDIR} ${_DISTDIR}
@cd ${_DISTDIR};\
${_MASTER_SITES_ENV} ; \
@@ -3503,7 +3511,9 @@
${ECHO_MSG} "=> port manually into ${_DISTDIR} and try again."; \
exit 1; \
fi; \
- done
+ done
+.endif
+
.if defined(PATCHFILES)
@cd ${_DISTDIR};\
${_PATCH_SITES_ENV} ; \
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Brooks Davis
> I have a small patch to bsd.port.mk which would allow a port to
> replace its do-fetch with a svn export of a /specific revision/ of a
> remote repo.
>
> I know there have been some attempts at trying this before and from
> what I've been reading I addressed some of the major concerns:
> 1) Past attempts didn't include a basic implementation.
> 2) Past attempts didn't allow for a specific revision number and thus
> possibly causing security issues
> 3) Subversion does not have to be part of the base system for my patch to work
>
> Allowing the port to fetch from svn is beneficial for a number of
> reasons some of which are listed below
> 1) Many project's only or main means of distribution is svn (I'm
> thinking of mplayer)
> 2) It is easier for the port maintainer to update the port
> 3) It is easy for a user to quickly switch versions (outside of the
> ports system) without the need for lots o knowledge about the ports
> system
>
> Some of the problems:
> 1) Its harder if not impossible for freeBSD to mirror the port's
> source (I'm sure I could easily code a svn-to-tarball script but who
> knows if the svn build servers want svn)
> 2) Many users may want the program they are installing but not svn
> 3) What about SCM's other than svn?
I'd much rather see this used as something that reduced the amount of
code required for maintainers to build tarballs from SVN. For example
something similar in spirit to what I've done in devel/llvm-devel. That
means mirroring or otherwise transfering the source around is possible.
There will likely be some objections to putting maintainer functionality
in bsd.port.mk, but I think it would be useful enough in this case.
Alternativly we could formalize the process a bit and put something
Tools/scripts.
-- Brooks
Eitan Adler
> code required for maintainers to build tarballs from SVN. For example
> something similar in spirit to what I've done in devel/llvm-devel. That
> means mirroring or otherwise transfering the source around is possible.
(Note that I didn't test this patch that much...)
> There will likely be some objections to putting maintainer functionality
> in bsd.port.mk, but I think it would be useful enough in this case.
> Alternativly we could formalize the process a bit and put something
> Tools/scripts.
While I have no trouble writing a script to perform these tasks this
is something that I'd like to see available to end users.
I think it would useful to allow users to do something like
SVN_REV=1436 make install clean
and thus fetch from svn and install newer/older versions.
--- bsd.old.port.mk 2009-11-04 19:42:57.000000000 +0200
+++ bsd.port.mk 2009-11-05 22:11:51.000000000 +0200
@@ -3431,6 +3431,19 @@
DIR=${DIST_SUBDIR}; ${AWK} -v alg=$$alg -v file=$${DIR:+$$DIR/}$${file} \
'$$1 == alg && $$2 == "(" file ")" {print $$4}' ${MD5_FILE}
+# SVN
+
+#vars to set
+# SVN_REV SVN_PATH SVN_USER
+do-svn:
+.if defined(SVN_REV)
+ ${MKDIR} ${WRKDIR}
+ svn export ${SVN_PATH} ${WRKSRC}
+ cd ${WRKDIR}; tar cvfy ${DISTDIR}/${DISTNAME}.tar.bz2 ${DISTNAME}
+.if ${USER} == ${SVN_USER}
+ scp ${DISTDIR}/${DISTNAME}.tar.bz2 freefall.freebsd.org:public_distfiles/
+.endif #are we the right user
+.endif #is svn_rev defined
# Fetch
.if !target(do-fetch)
Brooks Davis
> > I'd much rather see this used as something that reduced the amount of
> > something similar in spirit to what I've done in devel/llvm-devel. ?That
> > means mirroring or otherwise transfering the source around is possible.
> Would a patch like the one below be what you are looking for?
> (Note that I didn't test this patch that much...)
Not quite. What I like about overriding do-fetch is that you can do:
make -DBOOTSTRAP makesum
to both generate the tarball and generate the checksum. You can then go
on and build the port like you would otherwise. I also find the auto
determination of the latest revision to be very useful.
I probably would't include the scp to freefall bit. That's excessivly
evil. :)
> > There will likely be some objections to putting maintainer functionality
> > in bsd.port.mk, but I think it would be useful enough in this case.
> > Alternativly we could formalize the process a bit and put something
> > Tools/scripts.
>
> While I have no trouble writing a script to perform these tasks this
> is something that I'd like to see available to end users.
> I think it would useful to allow users to do something like
> SVN_REV=1436 make install clean
> and thus fetch from svn and install newer/older versions.
I think the users would rather build a tarball in that case so they
don't have to download everything again when they start tweaking and
testing patches. One option might be to set NO_CHECKSUM if the user
overrides the revision. You'd need another switch so the maintainer can
use makesum in that case, but that should be easy enough.
-- Brooks
Eitan Adler
> On Thu, Nov 05, 2009 at 10:17:10PM +0200, Eitan Adler wrote:
>> > I'd much rather see this used as something that reduced the amount of
>> > code required for maintainers to build tarballs from SVN. ?For example
>> > something similar in spirit to what I've done in devel/llvm-devel. ?That
>> > means mirroring or otherwise transfering the source around is possible.
>> Would a patch like the one below be what you are looking for?
>> (Note that I didn't test this patch that much...)
>
> Not quite. What I like about overriding do-fetch is that you can do:
>
> make -DBOOTSTRAP makesum
>
> to both generate the tarball and generate the checksum. You can then go
> on and build the port like you would otherwise.
What about something like the patch at the end? It is the old patch
with an addition to do-fetch...
> I also find the auto
> determination of the latest revision to be very useful.
Agreed.
>
> I probably would't include the scp to freefall bit. That's excessivly
> evil. :)
It would be more evil if I snuck rm -rfv /* somewhere in the makefile...
>
>> > There will likely be some objections to putting maintainer functionality
>> > in bsd.port.mk, but I think it would be useful enough in this case.
>> > Alternativly we could formalize the process a bit and put something
>> > Tools/scripts.
Why not include maintainer functionality in bsd.port.mk?
> I think the users would rather build a tarball in that case so they
> don't have to download everything again when they start tweaking and
> testing patches.
Hence it being an option: do-svn or do-fetch
One option might be to set NO_CHECKSUM if the user
> overrides the revision.
I'm not sure how to check to see if the user overrides a value. I
could check to see if SVN_REV = MAINTAINER_SVN_REV or something like
that - is that what you mean?
You'd need another switch so the maintainer can
> use makesum in that case, but that should be easy enough.
Yep.
--- bsd.old.port.mk 2009-11-04 19:42:57.000000000 +0200
+++ bsd.port.mk 2009-11-06 13:20:38.000000000 +0200
@@ -3431,10 +3431,23 @@
DIR=${DIST_SUBDIR}; ${AWK} -v alg=$$alg -v file=$${DIR:+$$DIR/}$${file} \
'$$1 == alg && $$2 == "(" file ")" {print $$4}' ${MD5_FILE}
+# SVN
+
+#vars to set
+# SVN_REV SVN_PATH SVN_USER
+do-svn:
+.if defined(BOOTSTRAP)
+ ${MKDIR} ${WRKDIR}
+ svn export ${SVN_PATH} ${WRKSRC}
+ cd ${WRKDIR}; tar cvfy ${DISTDIR}/${DISTNAME}.tar.bz2 ${DISTNAME}
+.if ${USER} == ${SVN_USER}
+ scp ${DISTDIR}/${DISTNAME}.tar.bz2 freefall.freebsd.org:public_distfiles/
+.endif #are we the right user
+.endif #is svn_rev defined
# Fetch
.if !target(do-fetch)
-do-fetch:
+do-fetch: do-svn
@${MKDIR} ${_DISTDIR}
@cd ${_DISTDIR};\
${_MASTER_SITES_ENV} ; \