[2026-02-11T08:42:00Z] where sewn [2026-02-11T08:54:46Z] wild, just found this when looking at illilitis repos: https://github.com/golang/go/issues/49383 [2026-02-11T08:54:52Z] maybe i shouldn't be using go [2026-02-11T11:12:56Z] told you go bad kris_ lol [2026-02-11T11:13:14Z] also, yeah, sewn has been away for some time now it seems [2026-02-11T19:59:52Z] hm. whats you guy's thoughts on an issue I have; Ive been working on a package manager in rc, and I wanted to support git submodules. but checking for a submodule is somewhat iffy [2026-02-11T20:00:05Z] I dont want to force cloning with submodules [2026-02-11T20:01:29Z] so my thought is this, either I hardcode some value in version file, i.e. git+$version $rev, and grep for git being here. oor move that out of the package manager, so its handled individually per package instead [2026-02-11T20:01:51Z] whats your thought on this? im open for other suggestions too obviously [2026-02-11T20:21:22Z] sad_plan: is it a kiss compatible package manager or something new? [2026-02-11T20:21:47Z] here on kiss submodules are manually handled in the source files [2026-02-11T20:23:29Z] dery: technically its something new, but im taking ideas from kiss, aswell as oasis. I initially inteded it to be mostly like kiss, or atleast feel familiar to kiss users. but I wanted submodule support, as opposed to how kiss handles git packages. I never like how that worked really, because it requries internet to build the package [2026-02-11T20:24:46Z] well if you do it like this, not really, it doesn't require building the package [2026-02-11T20:24:49Z] sorry [2026-02-11T20:24:52Z] it doesn't require internet* [2026-02-11T20:25:35Z] it's somewhat the kiss approach to encode these "third party packages" in the sources file. I don't necessarily love it but it seems to work somewhat ok [2026-02-11T20:26:24Z] I guess you could add a cached "post-download" step too and do `git submodule update --init` there [2026-02-11T20:26:35Z] exacly. I like being able to download everything required, then build everything regardless of connection. with git packages on kiss, thats not possible. iirc, kiss will error? or maybe I misremember it [2026-02-11T20:27:14Z] sad_plan: AFAIK there's not technical reason why it should error. Although I remember it erroring offline with ANY git source [2026-02-11T20:27:24Z] it's likely a bug IMO, but it never got fixed [2026-02-11T20:28:09Z] IIRC it even errors with the same hash already locally available, I suppose it's because kiss' scripts are ran with `sh -e` and the git call never got handled correctly [2026-02-11T20:28:59Z] hm. perhaps. I did write some code like oasis has, which acts as a way to write a custom script for unpacking. its technically called fetch, which would assume it has something to do with downloading. but oasis doesnt do it like this. which I know was the reference here [2026-02-11T20:29:43Z] yeah that might be the case. I just remember never liking git packages, so I opted to have github give me a commit tarball instead [2026-02-11T20:31:06Z] oh right, well, I guess you could use commit tarballs too for submodules [2026-02-11T20:32:33Z] well, I could, but ever since starting to use oasis, I always found this to be a worse solution than using git submodules. [2026-02-11T20:32:42Z] packages like sbase also doesnt give you that option [2026-02-11T20:33:12Z] stagit doesnt give you the option to hand over a tarball [2026-02-11T20:33:25Z] so in these instances its either a git checkout, oor a git submodule [2026-02-11T20:33:43Z] or Id have to create a fork for it on github, and point to it. which feels unneccessary [2026-02-11T20:34:51Z] my only gripe with submodules is if you change url or branch. other users have to manually fix it. atleast to my knowledge [2026-02-11T20:36:31Z] but back to the post-download script you mentioned. seeing as I already have the code for my fetch.rc script, which is supposed to run instead of the builtin unpacking, I can move it, and have that script handle submodules [2026-02-11T20:36:42Z] so rcpm can in this case just check for the existens of this [2026-02-11T20:37:31Z] another issue with git submodules is some pacakges also might have both a tarball download, aswell as a submodule. which said script can potentially take care of [2026-02-11T20:37:56Z] I think this might work. whats your thought about that dery? [2026-02-11T22:50:46Z] hi sad_plan, sorry, I was having dinner xD [2026-02-11T22:52:29Z] no worries :p [2026-02-11T22:53:48Z] I'm not sure I understand your plan completely. [2026-02-11T22:54:12Z] what you mean by "have that script handle submodules"? [2026-02-11T22:56:25Z] similarly to kiss, I added support for this script. its just called fetch.rc. its from oasis initally, as its used for some packages requiring some special rules for unpacking the tarball. I added the code for this, but have yet to use it [2026-02-11T22:56:51Z] well you'd have to cache its result somehow but yea, that would probably do it [2026-02-11T22:56:53Z] if i instead move this script, or rename it, or w/e. I can instead make a switch, checking for this files existence, and act accordingly [2026-02-11T22:56:55Z] same for rust/go/python stuff [2026-02-11T22:57:04Z] or java, damn is that annoying to fetch [2026-02-11T22:57:42Z] so say if I use a submodule in the case of say sbase, as I previously mentioned. I would include said file with the proper commands to fetch sbase's sources, then just move onto cd into srcdir, and build. [2026-02-11T22:58:28Z] Im activly avoiding rust/go. python, not possible for me, but yeah. python on my end is just a handfull of packages required :p [2026-02-11T22:58:35Z] yeye just saying [2026-02-11T22:58:54Z] like, there are multiple reasons to have a fetch script and IIRC at least a few major ones have something similar [2026-02-11T22:59:17Z] in any case, if a package uses submodule AND a tarball, I could make another switch checking for url (sources on kiss) file, and proceed as normal [2026-02-11T22:59:21Z] yep [2026-02-11T22:59:53Z] this is the thing I'm not completely sure I understand, what switch? [2026-02-11T23:00:10Z] ah, right [2026-02-11T23:00:18Z] with kiss we have an "output" field for sources, so nothing is left to the package manager (outside of single-tar cases) [2026-02-11T23:00:49Z] test for fetch script, run fetch script, test of sources file, if its there, download sources from there, and proceed to unpack tarballs on top of submodule [2026-02-11T23:00:59Z] did that make more sense? [2026-02-11T23:01:03Z] yea it does [2026-02-11T23:01:21Z] well I think it could "overlay" the sources, not the opposite [2026-02-11T23:01:38Z] like I see them as separate optional steps [2026-02-11T23:01:49Z] FWIW they could both be missing in a valid package [2026-02-11T23:02:24Z] I really think the only mandatory info, in something modeled like kiss packages, are build and version [2026-02-11T23:02:37Z] thats probably what I mean. on oasis, git uses both, and the manpage tarball is just extracted into the srcdir. terribly simple, which is what I want [2026-02-11T23:03:08Z] yeah, I think thats correct. version and build is hard requirement [2026-02-11T23:03:30Z] I think we're roughly on the same page then :D [2026-02-11T23:03:39Z] I think so :p [2026-02-11T23:03:51Z] that said judging from your previous messages I'd put tar unpacking *before* fetching [2026-02-11T23:04:14Z] FWIW I'd get rid even of that, automatic extraction that is, in a simpler package system :P [2026-02-11T23:04:42Z] kiss' semantics are somewhat weird [2026-02-11T23:04:48Z] I think git errors on existing directory, so i dont think we can untar first, then clone submodule :p [2026-02-11T23:05:44Z] yeah, this is where im kinda drawn. I like how kiss does this, and everything just happens in the background. buuut you lock things in instead. this is where im kinda drawn torwards separating most of the package managers stuff into the buildscripts instead [2026-02-11T23:05:53Z] well that's the thing though, fetching is supposed to run _before_ actual compilation [2026-02-11T23:06:03Z] you're supposed to cache its results and then do something with it [2026-02-11T23:06:09Z] so it doesn't matter what git thinks :P [2026-02-11T23:06:09Z] like derivelinux does on their end. I did a similar thing on my service manager [2026-02-11T23:06:24Z] nice [2026-02-11T23:07:29Z] well yes ofcourse, but git wont allow you to unpack the tarball, then clone the submodule. it should, if adhering to git clone's behviour, error out because dir already exist. hence; clone submodule first, (optinally unpack any tarballs). [2026-02-11T23:08:27Z] but git won't be running at all in the first place [2026-02-11T23:08:50Z] yes, its kinda nice. in that case, the package manager (or service manager in my case), just acts as a wrapper. all services can be launched manually, should say the service manager break. I anticipate my package manager to break at times, so being able to build packages regardless of the package managers state [2026-02-11T23:09:01Z] it will, if its told to [2026-02-11T23:09:47Z] how are you planning to make that run offline? [2026-02-11T23:09:50Z] see here: https://github.com/hovercats/rcpm/blob/master/rcpm#L108 [2026-02-11T23:10:10Z] itl work offline once you fetched the submodule initially [2026-02-11T23:10:22Z] then why do you need to run submodule update? [2026-02-11T23:10:27Z] it's just a directory [2026-02-11T23:10:46Z] first to fetch the submodule, then to check it out to a clean state [2026-02-11T23:10:55Z] fetch from where, if you're offline? [2026-02-11T23:10:57Z] a local path? [2026-02-11T23:11:19Z] ...obviously youd need internet the first time when downloading everything [2026-02-11T23:11:26Z] I think we're missing a step here [2026-02-11T23:11:37Z] maybe im just terrible at explaining [2026-02-11T23:11:42Z] no no no worries [2026-02-11T23:11:50Z] I'm taking for granted my understanding, that's my fault [2026-02-11T23:12:13Z] my idea was to make it a separate step, akin to downloading, where it just runs something and saves stuff into (a?) file(s?) [2026-02-11T23:12:25Z] but I think what you're doing is putting everything into a single archive? [2026-02-11T23:13:40Z] yes, everything goes into $pkg/src like it does on oasis. [2026-02-11T23:13:47Z] be it submodule or tarball [2026-02-11T23:13:51Z] or both [2026-02-11T23:14:24Z] yea but how is that cached? [2026-02-11T23:14:33Z] I kinda assumed the tarball would be stored in one way, the rest in another [2026-02-11T23:14:34Z] under $pkg [2026-02-11T23:14:39Z] uncompressed? [2026-02-11T23:14:58Z] what is $pkg exactly, a directory? [2026-02-11T23:15:03Z] sorry I don't know oasis and such very well [2026-02-11T23:15:15Z] wait, are you refering to the prebuilt package, or the source tarball? [2026-02-11T23:15:39Z] this is all referring to pre-build [2026-02-11T23:15:46Z] as in, fetching and downloading [2026-02-11T23:16:12Z] $pkg in this case would just be the package directory. so on kiss its where the build file is, version, checksums etc... [2026-02-11T23:16:24Z] oooh I see [2026-02-11T23:16:30Z] ah, right. tarballs are downloaded into $pkg [2026-02-11T23:16:43Z] and the "custom" fetched stuff would go where? [2026-02-11T23:16:45Z] submodules are cloned as $pkg/src. tarballs are unpacked into $pkg/src [2026-02-11T23:16:52Z] with me? :p [2026-02-11T23:16:52Z] oh and everything is stored there? [2026-02-11T23:16:57Z] under $pkg/fetch [2026-02-11T23:16:59Z] yes [2026-02-11T23:17:01Z] oh aight [2026-02-11T23:17:01Z] like bsd does [2026-02-11T23:17:07Z] ok ok now I think I understand [2026-02-11T23:17:08Z] ty [2026-02-11T23:17:11Z] :D [2026-02-11T23:17:30Z] well I'm still not entirely sure why you could not make it work as download -> fetch [2026-02-11T23:17:44Z] but that's just a technicality [2026-02-11T23:18:11Z] oh wait I think I understand now, as you're running the thing in the source [2026-02-11T23:18:22Z] then my question shifts to why you would expect that directory to be non-empty [2026-02-11T23:20:32Z] its only relevant if its a submodule. if its off of a tarball, we just remove the dir, and unpack the tarball again. for submodules, we have to do a proper cleanup first [2026-02-11T23:20:46Z] which is what I did here https://github.com/hovercats/rcpm/blob/master/rcpm#L112 [2026-02-11T23:21:19Z] from my understanding, running that command will give us a clean slate. similarly to if you unpack a fresh tarball, or clone a repo for the first time [2026-02-11T23:21:48Z] yea it should [2026-02-11T23:22:14Z] ye [2026-02-11T23:22:33Z] actually [2026-02-11T23:22:37Z] I'm not sure if that would cleanup the submodules [2026-02-11T23:22:41Z] or just the main repo [2026-02-11T23:22:48Z] its for the submodule itself [2026-02-11T23:23:00Z] but you're updating the submodules in src? [2026-02-11T23:23:06Z] unless I'm misunderstanding the syntax [2026-02-11T23:23:30Z] yea I'm pretty sure you're running `git clean` there [2026-02-11T23:23:36Z] but submodules are separate repos [2026-02-11T23:23:42Z] again not sure if that would clean up inside the submodues [2026-02-11T23:23:53Z] well yes, we fetch it first, and do a checkout at the commit we're using, then reset. this in of itself is redundant, but if you do a rebuild, youre running into issues if you dont clean [2026-02-11T23:24:09Z] yea but that'll clean only the main repo [2026-02-11T23:24:36Z] no, we use -C so its inside src/. not toplevel git repo [2026-02-11T23:25:07Z] isn't src the main repo of the package [2026-02-11T23:25:21Z] correct [2026-02-11T23:25:30Z] which is what we want to make sure is clean each time [2026-02-11T23:25:42Z] yea but submodules are git repos in and out of themselves [2026-02-11T23:25:46Z] those aren't getting cleaned [2026-02-11T23:26:03Z] they are with `git -C src clean -xfdq` [2026-02-11T23:26:36Z] you sure? [2026-02-11T23:27:21Z] to the best of my knowledge, yes [2026-02-11T23:27:43Z] Im pretty sure Ive tested it. but now im unsure wether how extensivly ive tested it [2026-02-11T23:28:21Z] welp it's not doing that on my machine [2026-02-11T23:28:39Z] just tried on a random git tree I had (bloaty) and made a file into a submodule [2026-02-11T23:29:07Z] I mean that makes sense, submodules are not part of the main git repo, that's kinda the point [2026-02-11T23:29:16Z] git operations start and end at a single repo [2026-02-11T23:29:20Z] (usually) [2026-02-11T23:29:53Z] dunno if there's a cleaner way, but I think you could use `git submodule foreach --recursive` for that [2026-02-11T23:30:10Z] `git submodule foreach --recursive git clean -fdxq` [2026-02-11T23:30:19Z] just tested [2026-02-11T23:30:30Z] oh wait you probably want [2026-02-11T23:30:38Z] `git submodule --quiet foreach --recursive git clean -xfdq` [2026-02-11T23:30:47Z] or it'll spam "entering x" "entering y" [2026-02-11T23:35:09Z] hm. wierd. ive mustve done a poor job testing this. I tested it again now, and it does remove untracked file anyhow, but does not fix any uncommitted changes. so it kinda does half the job we want [2026-02-11T23:35:19Z] but yes, maybe your command is better here [2026-02-11T23:35:45Z] its probably less of an issue also if I dont use git am to apply patches like oasis does on submodules [2026-02-11T23:35:56Z] yea for sure [2026-02-11T23:35:57Z] just using patch, of git apply is probably better [2026-02-11T23:36:19Z] yea so you can restore [2026-02-11T23:36:26Z] in the case of not having to deal with local commits anyhow [2026-02-11T23:36:28Z] yes [2026-02-11T23:37:12Z] but, if im not mistaken, the --checkout flag on `git submodule update --init` should checkout at the correct commit. which makes it a non issue. but I have to verify that [2026-02-11T23:37:33Z] oh right [2026-02-11T23:37:42Z] ive been meaning to create a repo for packages using rcpm, but ive yet to do that [2026-02-11T23:39:17Z] also regarding the --checkout flag, its probably why running `clean -xfdq` alone doesnt suffice, as the first one will check you out at the correct commit, and `clean -xfdq` cleans out the rest [2026-02-11T23:40:31Z] dunno tried --checkout rn and it did nothing [2026-02-11T23:40:36Z] it just ignores the submodule [2026-02-11T23:41:43Z] I tested it in one of my repos, and --checkout did check me out at the correct commit, and `clean -xfdq` removed untracked content for me atleast [2026-02-11T23:42:33Z] in the repo's submodule? [2026-02-11T23:42:38Z] cause clean works in the current repo [2026-02-11T23:42:46Z] it's the submodules that are ignores [2026-02-11T23:42:47Z] ignored* [2026-02-11T23:43:41Z] hm, ok, so --checkout will remove any local commits, `clean -xfdq` removes untracked files, not belonging to git history. it seems to leave out untracked changes though [2026-02-11T23:43:56Z] I think you'll need restore for that [2026-02-11T23:44:27Z] yea, or a reset --hard works too [2026-02-11T23:44:31Z] oh right