Closed RainbowHackerHorse closed 8 years ago
i actually have a branch specifically for features to introduce after the mirrors are up, so i'll add this there. should streamline things a lot
Sounds good, please keep this todo up to date.
can you spec the hierarchy for where on the filesystem you want things laid out? e.g.
/path/to/filename-version.tar.xz (for the combined src tarball on the pkg mirror/host)
as far as internal tarball hierarchy, from the above, it sounds like you want a single dir to extract ('src'), and then inside there have the destination-structure.
additionally, since we're decompressing the source tarballs and recompressing anyways, what do you think of this? instead of e.g.:
src/bin/bash-$version/
we do:
src/bin/bash/
this way we won't have to edit the build script every time a new upstream source is released. thoughts?
Works for me. The script will need to generate a /VERSIONS.txt document stating what versions of each piece of software exist in the tree at any given time the tree is updates, but yeah.
update per a previous conversation (via irc private message, 02.29.2016 ~0145EST)
pur_src/{core,contrib}
pur_src/core will need to contain sourcedirs: bash binutils bzip2 check coreutils dejagnu diffutils expect file findutils gawk gcc gettext glibc gmp grep gzip linux m4 make man-db mpc mpfr ncurses patch perl sed tar tcl texinfo tzdata util-linux xz zlib
i have yet to implement contrib. but... in pur_src/contrib we need (so far) the sourcedirs: libressl ntpsec rc.subr rc zfs
Sounds good. But we forked rc and rc.subr, so those won't go in contrib. Otherwise, looks good
doubletrue. here's what i currently have in contrib:
[pur@archdev ~]$ ls -1 pur_src/contrib/ eudev libressl net-tools ntpsec versions.txt
cleaning up purbuild.sh to work with the new src tarball layout, but i think i have it licked. i didn't include zfs in contrib because i'm not sure how you want to do that (does it need to patch/build against the kernel sources, if you know?) via issue #15 and hold off on the rc stuff pending issue #13 (and issue #1) but this'll at least give a good alpha i think. once i get a good src tarball, how do you want that distributed? it might be a good idea for you to do a detached ascii-armored GPG signature (or i can, or we both can, or whatever). i have a .sha256 for it, but that's just for confirming the download. i also have an mtree spec file for the contents of the uncompressed tarball if someone wants to confirm the checksums of the entire source tree for base.
ideally you/we should sign all three of those files (because the more verification we have, the better- see the recent Linux Mint fiasco).
@RainbowHackerHorse SO! https://github.com/bts368/Pur-Linux/commit/7c9f46f3492ea3649991efd49a14b495d775e433
review that (especially the purbuild.sh stuff)- just had a successful build of the basic core with it using the newly structured tarball. (note to self- need to move pur_src/base to pur_src/core, "01:48:22
the relevant files are:
http://g.rainwreck.com/pur/pur_src.2016.04-RELEASE.tar.xz http://g.rainwreck.com/pur/pur_src.2016.04-RELEASE.tar.xz.sha256 and, not used in the script (since mtree has a linux port but it isn't in stock repos for almost any distro), but uses a freebsd-compatible mtree format for verification of actual source integrity: http://g.rainwreck.com/pur/pur_src.2016.04-RELEASE.mtree
these obviously aren't finalized (because no zfs or rc yet), but should give a good working model while those are worked out.
Go ahead and import into CURRENT.
src tree established, modifications to the build script implemented (not yet pushed- still undergoing testing of chrooted builds and contrib software)
Once upstream code mirrors are in place, alter code tarball creation and buildscript to use the new SRC layout directory, in line with the ultimate locations of software on the filesystem. Example: src/bin/bash-$version src/usr/bin/file-$version src/usr/sbin/portsnag.sh