Sorry for the late reply -- this is a fair criticism, and I agree with you on the
core issue: tagfiles stop being first-class citizens the moment the installer
exits. There’s no lifecycle connection to slackpkg -- by design.
That said, I’ve been experimenting with tagfiles as a deliberate project rather
than a convenience feature. I actively use this approach for a jump machine at
work, built on Slackware-current, and I keep the tagfiles updated as -current
evolves.
The cost is exactly what you describe: manually auditing dependencies and keeping
the set coherent over time. There’s no automation here -- just careful review and
explicit decisions.
In other words, tagfiles can scale -- but only if you accept that dependency
resolution becomes a human responsibility, not something Slackware tries to
infer or automate.
In practice, I treat these systems as intentionally “finished”: slackpkg is
used conservatively, often without install-new, and changes are explicit and
reviewed. It’s not elegant, but it’s honest -- and very Slackware.
I’d love to see better tooling around this, but I’m also wary of solving it in a
way that undermines Slackware’s transparency. Your idea of exploring tagfile
support in slackpkg is interesting precisely because it raises that question.
For completeness: to detect dependencies when building and updating these
tagfiles, I rely on an existing Slackware helper script that scans for broken
library links. This script helps *identify* missing dependencies, but it does
not resolve them or make decisions -- the review remains manual.
Script (by mozes@slackware.com, 2010):
https://git.sr.ht/~r1w1s1/slackware-scripts/blob/main/find-whatneedsrecompiling
Tagfiles repo (Slackware-current, used in practice, shared as reference):
https://git.sr.ht/~r1w1s1/slackware-tagfiles
npub177…teh9a
2026-01-03 00:34:50 UTC
in reply to nevent1q…294f
Author Public Key
npub1773c2kdhaf88lk6nntdudn2p74egzurcs528cnmltl6vmshltu2q0teh9aSeen on
wss://relay.momostr.pinkPublished at
2026-01-03 00:34:50 UTCEvent JSON
{
"id": "24ace96a0b8786104a063907a60bb85f29a24a45c8175d71b781016e91873100",
"pubkey": "f7a38559b7ea4e7fdb539adbc6cd41f57281707885147c4f7f5ff4cdc2ff5f14",
"created_at": 1767400490,
"kind": 1,
"tags": [
[
"proxy",
"https://snac.bsd.cafe/r1w1s1/p/1767400490.675716",
"web"
],
[
"e",
"9d7692172c2b343498e2f808378fae023f13a81462780fd37a750f63c3477029",
"",
"root",
"f7a38559b7ea4e7fdb539adbc6cd41f57281707885147c4f7f5ff4cdc2ff5f14"
],
[
"p",
"f7a38559b7ea4e7fdb539adbc6cd41f57281707885147c4f7f5ff4cdc2ff5f14"
],
[
"p",
"8afc54260e9ca6615d18086c721faebbfeac3920921d5a06616ea3df9b2d87ed"
],
[
"e",
"760af25033e26864e8768bc0056f5d2bc8d8e37252d0789a3985671e126fb381",
"",
"reply",
"8afc54260e9ca6615d18086c721faebbfeac3920921d5a06616ea3df9b2d87ed"
],
[
"proxy",
"https://snac.bsd.cafe/r1w1s1/p/1767400490.675716",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://snac.bsd.cafe/r1w1s1/p/1767400490.675716",
"pink.momostr"
],
[
"-"
]
],
"content": "Sorry for the late reply -- this is a fair criticism, and I agree with you on the\ncore issue: tagfiles stop being first-class citizens the moment the installer\nexits. There’s no lifecycle connection to slackpkg -- by design.\n\nThat said, I’ve been experimenting with tagfiles as a deliberate project rather\nthan a convenience feature. I actively use this approach for a jump machine at\nwork, built on Slackware-current, and I keep the tagfiles updated as -current\nevolves.\n\nThe cost is exactly what you describe: manually auditing dependencies and keeping\nthe set coherent over time. There’s no automation here -- just careful review and\nexplicit decisions.\n\nIn other words, tagfiles can scale -- but only if you accept that dependency\nresolution becomes a human responsibility, not something Slackware tries to\ninfer or automate.\n\nIn practice, I treat these systems as intentionally “finished”: slackpkg is\nused conservatively, often without install-new, and changes are explicit and\nreviewed. It’s not elegant, but it’s honest -- and very Slackware.\n\nI’d love to see better tooling around this, but I’m also wary of solving it in a\nway that undermines Slackware’s transparency. Your idea of exploring tagfile\nsupport in slackpkg is interesting precisely because it raises that question.\n\nFor completeness: to detect dependencies when building and updating these\ntagfiles, I rely on an existing Slackware helper script that scans for broken\nlibrary links. This script helps *identify* missing dependencies, but it does\nnot resolve them or make decisions -- the review remains manual.\n\nScript (by mozes@slackware.com, 2010):\nhttps://git.sr.ht/~r1w1s1/slackware-scripts/blob/main/find-whatneedsrecompiling\n\nTagfiles repo (Slackware-current, used in practice, shared as reference):\nhttps://git.sr.ht/~r1w1s1/slackware-tagfiles",
"sig": "5ca81b15ed691ce7dcef6966fe3694b6392cf41b3439069ce769d5ee3dd3e005aca7c650fbb554283da04f81704525a45c308ac76817c3e10688177c522ee3a7"
}