On Jul 14, 2013, at 12:06 AM, Garrett Wollman wrote: > In article <20130714064601$3ce5_at_grapevine.csail.mit.edu>, > dteske_at_freebsd.org writes: > >>> [I wrote:] >>> It accesses the sqlite database in /var/db/pkg that was previously >>> retrieved from the remote repository. > >> 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. > > Only if you update /usr/local/etc/pkg.conf to set a permanent > PACKAGESITE. Otherwise, it will notice that the remote repo catalog > you have isn't for your currently selected remote repo, and use that > instead. > >>> 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. > > Congratulations for building your entire workflow around a horrible > kluge straight out of 1993. Prejudice much? > FreeBSD, however, is moving on. Moving from tarballs to tarballs, yep... moving along nicely. > (And > it's long past time!) I love your enthusiastic embrace. > Your developers will just have to deal. You're making the wrong argument. Bringing in a new package system doesn't help developers or integrators. It doesn't matter if you switch "pkg_create" with "pkg_create". Developers like being able to go into a build tree and say "make" and end-up with a package. How that build tree does it should be "sufficiently advanced enough to be indistinguishable from magic." Your answer implies that this infrastructure is unnecessary, when I can indeed tell you that even if it is not divulged to me what goes into a package, I'll still end up ripping it open and creating my own build platform that doesn't depend on platform-specific tools. And when the day comes that FreeBSD uses something other than tarballs, then I'll then force the developers to build the packages on the platform using said tools; but until then, why pigeon-hole the process of building a package into one OS when developers could care less whether their "make" uses pkg_create, pkg, rpm, dpkg, or what else? To give you an idea as to just how helpful this is... Imagine the following hierarchy: src/pkgbase/depend/mystuff/script1 src/pkgbase/depend/mystuff/textfile1 src/pkgbase/depend/mystuff/sourcefile.c src/pkgbase/depend/mystuff/Makefile You are a developer. You want to ship a package that contains "script1", "textfile1", and "binary1" (which is compiled by saying "make" to turn "sourcefile.c" into "binary1") You want to ship 8 types of packages: FreeBSD-4.11 FreeBSD-8.1 (i386) FreeBSD-8.1 (amd64) RedHat EL 4 RedHat EL 6 (i386) RedHat EL 6 (x86_64) Debian Wheezy Debian Wheezy 64-bit This is where my framework comes in-handy... cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff make # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and built the .tgz cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff make # it pulled the necessary bits from the "depend" dir and built .tbz cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff make # pulled in "depend" and made .rpm cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff make # pulled in "depend" and made .rpm etc. Of course, *any* time the depend tree has binaries in it... you have to first do a make in there on the platform you want to ship the binary for, and then do "make depend" in the platform-specific tree to pull in the binaries. Once you've done that, you don't have to muck with the depend tree again unless there are changes there. So, I assume that your prejudice remarks are because you haven't either seen (a) such a platform or (b) such a need for said platform. Yeah, I could rewrite the freebsd-specific logic to use "pkg create", but let me tell you... When you have to touch a file that needs to get shipped out to multiple platforms... It's damned nice to be able to build the FreeBSD packages under RedHat *BECAUSE* the redhat RPMs can't be built under anything else (building an RPM on FreeBSD and attempting to install it on RedHat results in an error message similar to "this is an rpm for FreeBSD; go away"). Whereas FreeBSD will never balk about a package built on another platform. It's a huge time-saving measure... not having to jump over to each/every unique platform to package things up *IF/WHEN* you know that there are no binaries in the package *or* you've already checked the pre-compiled binaries into the arch-specific hierarchy. > Or you > can maintain the old cruft for your business -- just don't expect > anyone else to use it, or even want to. > I have no intention of making old-world packages... but I also have no intention of using "pkg create". -- 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 - 05:29:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC