On 10/04/2011 04:27 PM, Marc Espie wrote:
On Tue, Oct 04, 2011 at 02:44:42PM -0400, David Cantrell wrote:
On 10/04/2011 02:31 PM, Marc Espie wrote:
On Tue, Oct 04, 2011 at 02:11:13PM -0400, David Cantrell wrote:
On 10/04/2011 01:39 PM, Antoine Jacoutot wrote:
On Tue, 4 Oct 2011, David Cantrell wrote:
I'm working on a local port where the source archive is not available via
anything other than svn. I'm trying to use pre-fetch to see if a checkout of
the release I want already exists in /usr/ports/distfiles and if not, check it
out. I'm trying something like this:
Why don't you create a tarball of the checkout and host it?
That's not really the solution I'm after. The project itself does
not have a release engineer and I'm not looking to become one for
it. I am just trying to put together a local port that some other
coworkers can use to build packages of a specific checkout from the
svn repo.
Don't use pre-fetch, it's heavily deprecated. In fact, don't override
any of pre-fetch, do-fetch, post-fetch.
Noted. Please remove information about overriding *-fetch from the
bsd.port.mk man page.
Read more closely:
every configuration. Use of {pre,do,post}-fetch hooks is
strongly discouraged, and will probably be removed in the
near future, as this makes mirroring of distfiles very
complicated. See CHECKSUMFILES, CDROM_SITE, DISTDIR,
Yes, I saw that. It does say "probably" though. And it only says
discouraged, not deprecated.
Many would interpret the text to mean that while {pre,do,post}-fetch
hooks are still there, it's probably there for backwards compatibility
and you probably want to look at another way to do what you're trying to
do. But it doesn't indicate that the functionality will definitely be
removed or that it should not be used at all.
OK. But this is probably something worth thinking about for future
development. I've noticed many upstream projects eliminating
tarballs in favor of telling you a git tag to use 'git archive
--format=tar' on. While it may not be something anyone cares about
for the main ports tree, having the functionality there for people
who keep things in /usr/ports/mystuff would probably be useful.
Nope. Not good. checksums. How do you prevent people tampering from
upstream and introduce trojan horses ?
You don't and you don't care about that. I'm talking about extending
the infrastructure to support more fetch mechanisms. If people are
building from source anyway, especially locally managed ports, if it
breaks, they get to keep the pieces. You can't audit things you don't
ship, so why care?
My suggestion was to add support to the ports system infrastructure to
allow people an easy way to locally package up stuff from projects that
do not release tarballs. I'm not advocating eliminating checksums on
everything, nor am I advocating accepting ports in to the main ports
tree that work this way, nor am I advocating destruction of any existing
tried and true methods. I'm just pointing out that the infrastructure
as it exists could do with a handful of other fetching mechanisms to
make life easier for people making local ports. Ports they have no
interest in submitting to the main ports tree.
It's not like this never happened. We caught at least 2 such issues
thanks to the checksums in distinfo.
Right, and I'm not talking about changing anything in the main ports
tree to drop checksums. I'm merely suggesting introducing additional
mechanisms by which people can easily package things on their own
systems from projects that do not release tarballs. I'm not advocating
AGAINST using checksums.
--
David Cantrell <david.l.cantr...@gmail.com>
WH6DSN | http://blog.burdell.org/
