Re: [HEADSUP] No more pkg_install on HEAD by default

From: Teske, Devin <Devin.Teske_at_fisglobal.com>
Date: Sun, 14 Jul 2013 06:45:54 +0000
On Jul 13, 2013, at 11:13 PM, Garrett Wollman wrote:

> In article <20130714054840$7f8f_at_grapevine.csail.mit.edu>,
> dteske_at_freebsd.org writes:
> 
>> How about rquery? What protocol does that use? and what does it talk to?
> 
> It accesses the sqlite database in /var/db/pkg that was previously
> retrieved from the remote repository.
> 

This "previously retrieved" has me worried.

One of the things that you could do with sysinstall was:

1. Browse packages (nothing else)
2. Exit sysinstall

And your system is completely unmodified and the mirror your chose is forgotten.

Now from what you explained of pkg, I'm worried that for bsdconfig:

1. Browse packages (nothing else)
2. Exit bsdconfig

and now because the "pkg rquery" has staged a db, future "pkg" commands are now influenced.

In which case, I think I would best off downloading the sqlite db to a temporary location and pointing pkg at it (if that's possible). Because I'm not sure that I want adhoc browsing in bsdconfig to change the default mirror (but maybe that's desired? I'm not sure).



>> Question: Where can I learn more about the actual format of what's in
>> the new tarballs? This is going to be important not for bsdconfig, but
>> $work (we have our own build platform; I'm going to have to rewrite it
>> from mastering PLIST files to mastering YAML MANIFEST files and I want
>> to know all the gritty details).
> 
> You really shouldn't know about the actual format of the tarballs;
> your time would be better spent learning the new "pkg create", "pkg
> register", and "pkg repo" commands.  Depending on your needs, you
> might want to write to the libpkg API instead.
> 

That won't work for us.

You're not going to like the answer, but it does mean that things like "pkg create", "pkg register" and "pkg repo" won't work for us.

Because FreeBSD packages are just tar-balls, I created a build-system that allows us to master and re-master them on *any* platform with nothing more than "make" and a few standard UNIX utilities such as "awk" and etc. This makes it extremely convenient for developers and integrators. You can feel free to check out the build tree on Mac OS X, make some changes to a file, check them in, build the package, throw it in the repos, and all from the comfort of your own OS.

Yes, it flies in the face of "dog-fooding", but the value-add that it brings to the table is quite tangible w/respect to our workflow.

So the format is still something I want to know quite well.
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Received on Sun Jul 14 2013 - 04:45:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC