Hi Andrew Sayers,

I wonder why you add more and more content here, which IMO is not related to system Build Tools. For e.g. - Package checker tools - Package maintenance tools - Automatic Packaging Tools

Please let's focus on the topic _system_ build tools and not add any 'whatever' build tool here. Therefore, you can create seperate pages.

Here's the page before my first edit, which includes a "Package build tools" section. That section has been there since version 1, so I assumed it was relevant to the topic. And if package-building is relevant, so is package-checking, and so on.

Here are some sections where it would be particularly difficult to decide which page they'd go in:

• "Unpack/configure packages to a location" discusses tools that are theoretically about making systems, but are most often used for creating packages
• "App container related" is about tools that explicitly reject the idea of building systems
• "Service container related" is about containers that inherently blur the line between packaging and systems

  • see also PackagingWithDocker

I've taken the position that there's no bright line distinction, so the page might as well represent the whole spectrum. Where would be a better place to draw the line? Which side of the line would the above sections go in, and why?

-- ?AndrewSayers 2025-05-23 18:38:31

Hi Andrew, OK, I see that "Package build tools" section was there before your first edit. Sure, it's hard to choose where to draw the line and there may are different opinions. For me building a chroot environment for building a package is the last thing I would add to this page. Building live ISO is more related to systemd building. And building containers (service and app containers) is related but should be on a page its own.

But package checking is clearly out of scope. Otherwise you may start adding infos about dpkg and so on.

In the end the page should not become too long and stay focused on the main topic.

And BTW, listing historical tools make no sense IMO.

P.S.: I do not say that all this was added by you, but please think what content makes sense for the readers of this page. Instead of adding more content it's sometimes useful to reduce the amount of information or move content to a separate page.

-- ?ThomasLange

Hey,

Having thought it over, I propose dealing with some of the edge cases first, then coming back to the big question. How about...

1. FreedomBox should be a bulleted list on CategoryFreedomBox, linked from a "related tools" section in "see also", and the section removed from this page

2. App container related should be a bulleted list in PackageManagement, linked from a "related tools" section in "see also", and the section removed from this page

3. Service container related should be removed, and the bullet point in "see also" should just point to Docker and Podman

4. Derivatives should be removed, and the bullet point in "see also" should contain the text of that section

5. Other should be removed - most of the links are dead, it can be a bullet point if there's anything left to point to

6. Historical should be removed - I agree these have outlived their usefulness

7. an admonition should be added to the top of the page about how the page might get split, and pointing to this discussion

I feel like that would clear out the edge cases, leaving one "packages" cluster and one "systems" cluster. And if we leave the admonition up for a week, anyone that thinks otherwise should have time to give their two penneth.

-- ?AndrewSayers 2025-05-23 21:01:37

That alls sound very good to me. Go ahead. IMO the packages cluster might later be moved to a separate page.

-- ?ThomasLange

Updated. Some wrinkles for the record:

• a few links turned out better in other places (e.g. most of "FreedomBox related")

• I've split the page in two and put the admonition at the top of the " Packaging tools" section, which feels like a more obvious way to tell the story
  • I've reinstated "Automatic debian/copyright tools", which IMHO is helpful to tell the story about why the page should be split - hope that's OK

• the "See also" section contains a "Package/system hybrids" group, which might want to go on a little page that gets <<Include()>>ed from both sides of the split

• I said "leave the admonition up for a week", which is IMHO a minimum for such a big change, but I'm busy next weekend so it might be more like 10 days

-- ?AndrewSayers 2025-05-24 12:08:20

All done! I took the opportunity to reformat PackagingTools based on the layout of DebianRepository/Setup. Let me know if anything else needs doing.

-- ?AndrewSayers 2025-06-03 17:32:40