Conclusion

It appears that any end-user changes are likely to be rejected. It also appears that any changes to bsd.*.mk are likely to be rejected. My best bet is to add a script to Tools/ - this is something that maintainers already do on their own...

Proposal

I'd like to see the ports system let you use svn (or other SCMs) fetch the code instead of using a tarball

An earlier (but slightly different) proposal.

Reasons

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

Solved 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
  4. I could easily code a svn-to-tarball script and the maintainers would upload the code to freefall
  5. It is possible to track port updates which this method. The only change occurs in the /fetch/ stage so versioning works.
  6. Distfiles can be (by default?) saved into the normal distfile directory and be updated with a fresh export or update.
  7. SVN checkout would not be signed; only the tarball would be checked.

Unsolved Concerns

Things the system should do (AKA a spec)

  1. Provide a target for any user to checkout from a specific revision

    • (be careful that svn is build with proper support for http:// or svn://

    • a) Tar the checkout and perform the checksum on the tarball (Build tar without timestamps because otherwise checksums will fail)
    • b) Do a checksum on the checkout itself and only make the tarball when BOOTSTRAP is defined

      • (Doesn't svn have a key that it asks you to trust -> maybe check against that)

  3. Either way provide a fallback for users who can't or don't want svn
    • (does svn use $? to tell us when it failed)

Possibilities

  1. Use SVN to fetch for the user directly (my preferred option)
  2. Use SVN to let maintainers upload source as a tarball (bootstrapping like comms/wspr)
  3. Write a script to do bootstrapping (instead of making it part of bsd.ports.mk
  4. Running "make fetch" would perform an svn export/checkout, and would generate a tarball from this in ${DISTDIR} named as ${PORTNAME}-${PORTVERSION}.t[gb]z.

Implementations and patches

  1. Method 1 - first attempt

  2. Method 2 - first attempt

  3. Method 2 - second attempt

  4. Marcin Wisnicki's idea

  5. Method 4 - first attempt

Ports to look at that use svn in some manner

EitanAdler/ports-svn (last edited 2010-11-05T20:36:30+0000 by EitanAdler)