Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Dec 1997 00:41:23 -0700 (MST)
From:      bgingery@gtcs.com
To:        fenner@parc.xerox.com
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Recommended added target for bsd.port.mk 
Message-ID:  <199712170741.AAA12328@home.gtcs.com>
In-Reply-To: <97Dec16.192102pst.177480@crevenia.parc.xerox.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Dec, Bill Fenner wrote:
-} bgingery@gtcs.com wrote:
-} >Whoops - time to upgrade my bsd.port.mk, I guess.
-} 
-} Nope, I was making a suggestion, not offering something that already
-} exists.

    Ahhh.  Okay.  The exact performance isn't particularly important,
    although no real reason to repeat the "describe" target, per se.
    Personally, I *very* seldom use "make describe" but *do* use my
    shell alias "desc" which is merely a "more pkg/DESCR", and the
    (currently also a shell alias) "installed" which does what I
    described, passing `make package-name` to pkg_info -c.

    I also use `make package-name` for easy package deletes, which
    could be a "make delete" target, very easily, too.  I do that
    seldom enough that I've not even made an alias for it.


    OTOH, to be consistent with handling pre-req's, a "make delete"
    should be interactive only (under normal operation) and remove
    packages which are registered as dependent on the port, as well. 

    Then, too, there are enough bsd.port.mk targets now, that a "make
    help" is almost in order, even if it merely extracts the lines that
    describe the targets from itself.

    I know a few people have expressed a wish to re-do the whole ports
    handling methods, yet it's quite powerful as is.  Personally, I'd
    rather see a "make installbin" invoke a fetch of the binary package
    and install it, adding to the process, than a replacement of what's
    already working so well.

    Yet, also, with someone recently, I mentioned the prospects of
    storing the ports tree in a series of zip-files by type ..e.g.
         /usr/ports/archivers.zip   (etc.)
      or even
         /usr/ports/archivers/zip.zip (etc.)
    and only extracting what's needed for making a port.  That would
    require changes to bsd.port.subdir.mk, though, to handle the
    compressed port tree.  "make all <targetlist>", or "make <subdir>
    <targetlist>" from the parent directory.

    The *reason* for using .zip rather than .tar.gz was twofold.
    New "port tarballs" could easily be distinguised from package
    tars by their "zip" extension.  The space taken would decrease
    significantly.  Individual *known* files could be extracted
    by the bsd.port.subdir.mk other targets, easily for mass processing.
    without the overhead of handling all of the patches or scripts that
    might be in an existing port.  This would be especially handy for
    targets like "fetch-list" and "describe" and "readme".

    I'm already using a Perl script for resolving *some* URLs on my
    website for infrequently accessed files.  It merely returns HTTP
    headers and unzips to stdout of the file requested (if approved).
    
    	Bruce Gingery	<bgingery@gtcs.com>





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712170741.AAA12328>