From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 18:54:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBB611D8; Sat, 13 Jul 2013 18:54:24 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 885B21CB6; Sat, 13 Jul 2013 18:54:24 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r6DIsNED018490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Jul 2013 13:54:23 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sat, 13 Jul 2013 13:54:23 -0500 From: "Teske, Devin" To: Kimmo Paasiala Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOf1XlEhI/XtjETUan8/QjEhM8ppliCtaAgACKXACAAHg7gIAAGMOAgAAZGQCAAAqhgA== Date: Sat, 13 Jul 2013 18:54:21 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-13_07:2013-07-12,2013-07-13,1970-01-01 signatures=0 Cc: Baptiste Daroussin , Devin Teske , "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:54:24 -0000 On Jul 13, 2013, at 11:16 AM, Kimmo Paasiala wrote: > On Sat, Jul 13, 2013 at 7:46 PM, Teske, Devin = wrote: >>=20 >> On Jul 13, 2013, at 8:17 AM, Teske, Devin wrote: >>=20 >>=20 >> On Jul 13, 2013, at 1:07 AM, Baptiste Daroussin wrote: >>=20 >> On Fri, Jul 12, 2013 at 11:52:19PM +0000, Teske, Devin wrote: >> On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote: >>=20 >> Hi, >>=20 >> I have just committed (r253305) a change the make pkg_install not being = built >> and installed by default on HEAD. >>=20 >> If you are still relying on it, be careful and add WITH_PKGTOOLS=3Dyes i= n your >> src.conf(5) >>=20 >> [snip] >>=20 >> I for one am effected and will have to change things. >>=20 >> If you are referring to bsdconfig's package management, >>=20 >> [snip] Yes. that's what I'm talking about. [snip] >>=20 >>=20 >> it is not working anyway >> HEAD as we do not and will not provides any pkg_install for HEAD via any= of the >> usual distribution process: http, ftp, CD. >>=20 >>=20 >>=20 >> The FTP mirror of packages is going away? (if you said yes and pointed a= t a prior conversation about leading up to this, I would not be surprised -= - I'm just questioning it because I don't see the value in pairing-down met= hods of acquisition) >>=20 >> If this is the case, what's the surviving acquisition method? A custom T= CP protocol perhaps? >>=20 >> There may be those that wish to use pkg in the pkg_add manner and downlo= ad things and then inspect them manually before adding them. For example, I= often go the freshports.org= to find a package that fills a need... download it from the official FTP s= erver(s), inspect all of them, and choose the one that best fits me need (a= nd only then installing from the local file; tossing the rest). If I go thr= ough the "pkg" tool, I have to inspect things *after* they've been installe= d which is not to my satisfaction. >>=20 >>=20 >> [snip >> bsdconfig is not installed by >> default, >>=20 >> Wrong, please see... >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D252862 >> [snip] >>=20 >> The first thing that comes to mind in reprogramming bsdconfig's package = management for pkgng... >>=20 >> We have a *very* large list of FTP mirrors. This will presumably be repl= aced with a list of "pkg" mirrors. >>=20 >> Do we have such a list that we want to program into the base configurati= on of bsdconfig? >> -- >> Devin >>=20 >=20 > Come on, this only concerns 10-CURRENT. Right; which is why -current is CC'd. > Where is it stated that the > FTP mirrors for FreeBSD 8/9 packages are going away? >=20 I don't know where you got the impression that I was concerned with 8/9 pac= kages. I'm strictly concerned with HEAD and strictly concerned with planning for t= he future. So yes... I'm asking... in a HEAD world, what is the "officially supported"= method of acquisition? I saw mention on a page that "rsync access will provided for those who want= to mirror" but my I'm not really interested in mirroring while I would lik= e to continue to be able to grab packages myself without installing them. Maybe the answer is that "pkg" has a method of acquiring a single package (= without dependencies) without downloading it. That would solve my personal = workflow issue (again, I like to download tarballs, inspect them, and then = install them from the locally downloaded file -- then if it passes validati= on tests, that downloaded file is migrated to our own distribution servers;= it's a work-flow for validating packages -- it has less to do with how pkg= ng works and more just whether I can get packages in a fashion such as FTP = or HTTP or whatever. Now that aside, bsdconfig currently is a different story. To rewrite the pa= ckages module to work in a HEAD world for HEAD, using pkgng servers, I'm go= ing to have to change the way things are done. Currently there is an abstra= ction layer for fetching packages from media (which can be FTP, HTTP, HTTP = Proxy, NFS, Local Directory, CDROM, a DOS partition, a UFS partition, and [= god forbid] Floppy -- with perhaps SMB/CIFS down the road). When it wants t= o add a package, it calls the routine to get the package data by name on st= andard-out and pumps it into pkg_add (after of course initializing the medi= a). This abstraction layer is useful to pkgng as it prepares the source. What I= *suspect* will have to stop happening is the direct-fetching of the packag= e data and piping that into a program (however, I *could* continue to do th= at .. "pkg" supports adding of local packages and iirc supports reading fro= m standard-in). Instead, perhaps just call "pkg" in a small-handful of diff= erent ways (pointed at an ftp server; pointed at a local file; pointed at h= ttp; etc.). But the preparation of an NFS mount would be handled by the abs= traction layer leading up to the calling of pkg. That issue aside (whether to have pkg do the bidding or to use the existing= abstraction framework to fetch the file), there are benefits to each route. I'm leaning the latter route (of having bsdconfig's abstraction layer do th= e fetching and simply have pkg add a file from stdin) because I can then wr= ite a program that is essentially a more advanced version of sysutils/pv (a= nd would be BSD licensed). There are certainly things that pkg can excel at that the latter method may= by-pass (which might make it undesirable). For example, bsdconfig currentl= y reads the INDEX file and handles dependencies itself. It could continue t= o do this, but we want pkg to handle the dependencies. If I chose to continue to do things in this manner, it would be bad (I esti= mate) because I believe that shoving dependencies into pkg in an ordered fa= shion before adding the requested package would ultimately cause the depend= encies to _not_ be recognized as leaves (correct me if I'm wrong), meaning = that something like "cutleaves" wouldn't be able to prune them from the thr= ee after the dependencies have been gone. So to take full advantage of all the features of pkg, I think I'll relegate= the idea of a sysutils/pv to working for the distfetch side of things (ano= ther topic) and just wield pkg in one of a small-handful of ways pointed di= rectly at media. Which brings us back around to the question at hand... Does it support FTP? HTTP? HTTP Proxy? Local File? (that's about all that I= need -- the last-one... Local File would be for repositories mounted via t= he preparation-framework which is part of the abstraction layer -- we'd jus= t ignore the acquisition methods thereof). If FTP access (or any of the other remote access methods) are going away fo= r HEAD pkg access, I'll need to know so I can make the appropriate changes = in the HEAD branch of bsdconfig. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.