Date: Sat, 13 Jul 2013 18:54:21 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Kimmo Paasiala <kpaasial@gmail.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, Devin Teske <dteske@freebsd.org>, "current@FreeBSD.org" <current@freebsd.org> Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> In-Reply-To: <CA%2B7WWSe7C2UXAsEX3OZH7nPJJbxotpQ_iYBxgake4R68sbUtLA@mail.gmail.com> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <CA%2B7WWSe7C2UXAsEX3OZH7nPJJbxotpQ_iYBxgake4R68sbUtLA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 13, 2013, at 11:16 AM, Kimmo Paasiala wrote: > On Sat, Jul 13, 2013 at 7:46 PM, Teske, Devin <Devin.Teske@fisglobal.com>= 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<https://urldefense.proofpoint.com/v1/url?u=3Dh= ttp://freshports.org/&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%= 2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DFt5J2W3Nm8xze74zARHsiglLFTGOYrxAzaubbP7wvcM%= 3D%0A&s=3Dcb1df85e237d1a6be19f981e8b352419dd056ea0f4e782b330cb9c7cfd15fda5>= 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201FC3FAA>