On Jul 14, 2013, at 11:27 PM, Baptiste Daroussin wrote: > On Sun, Jul 14, 2013 at 07:29:50AM +0000, Teske, Devin wrote: >> >>> 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". > > So you are taking as an exemple rpm but with RPM you do want to use what they > do > provide, aka rpmbuild but with pkgng you want to manually handwrite the > packages > because we haven't hidden the format behind opaque names and format. >
Close... I use rpmbuild because I haven't figured out how to subvert it to create cpio-balls for rpm(8). I know how to extract the contents of binary rpm's using rpm2cpio and I know how to extract the meta data and supplant it into a template SPECFILE using rpm -q -p file.rpm --qf "queryformat" ... but I haven't spent enough time with rpm's to know how to master them without rpmbuild. The best I've done is learn how to use ".rpmmacros" to make rpmbuild behave in a sane manner that is conducive to (a) building the archive out of the current directory (including all temporary files, etc.) and (b) working on source-controlled checkouts. However, even if I did figure out the cpio-ball/metadata format, it is quite convenient to have rpmbuild do the work -- which unfortunately introduces the constraint that you have to generate the archive on the system for which it will be installed (something you eluded that is inconclusive -- I'll cover that in a reply to that-reply directly). The convenience however is not because the tool does everything I need it to do, but the convenience comes from the translation of YAML into metadata. It doesn't appear that this will be necessary with pkgng packages, just as it wasn't necessary for pkg_install packages. To be more clear,... because tools like pkg_create and "pkg create" take a file-in, add data to it, and then (the most important part) put a modified form into the archive (which quite-closely resembles the original), it is then possible to imagine that: (1) there's value in learning both the input format and the output format so that you can validate packages, fix broken packages, etc. ASIDE: For example... a binary release package ends up with incorrect dependencies encoded within its +CONTENTS file -- I can slurp the package into our "pkgbase", adjust the PLIST (generated from +CONTENTS), and produce a fixed package in mere moments (and I didn't have to wake anybody in the middle of the night, ask that FTP mirrors be updated, balk at the core team -- none of that... the problem was solved and in the next release we hope for the best that the dependency chain isn't busted for the same binary package within the set of "X.Y-RELEASE" packages). (2) there's value in writing a shell-script method to translate the input format into the output format from a system of makefiles calling said shell scripts out of a revision-controlled checkout ASIDE: This one should be obvious. If you can assemble a package using nothing but shell scripts (and mostly awk, ls, find, cp, mkdir, ln, cvs, make, md5/sha256/sha512/openssl, and etc.), then you don't have to port the "port" system (our "port" system being called "pkgbase" -- and working to "keep you stable" rather than "keep you up-to-date"). > You know in that case you should probably create your own RPM without RPM just > write by hand the header and happened the cpio to it, in that case you will > end > up having the same at what you are trying to do with pkg. > It's a good idea... except one thing... the YAML SPECFILE (minus the elements that are specific to the `-bb' process of rpmbuild) get completely changed in the process. Doing this would require a YAML parser + metadata encoder process-pair. Whereas for FreeBSD it's YAML-in, YAML-out. So I don't need a YAML-parser, just a line-parser and light YAML-encoder -- which could be fixed-strings, doesn't have to be complex... e.g., awk). -- 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. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
