https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285253
--- Comment #7 from Gleb Popov <arr...@freebsd.org> --- (In reply to Chad Jacob Milios from comment #5) Ok, I'm now probably spreading FUD, so let me expand. The FreeBSD package building cluster runs Poudriere, so all ports being committed should be buildable by it. Committers are expected to verify that any change they're pushing is buildable in Poudriere. This makes Poudriere a "blessed" build tool, because it is used by portmgr@ and pkgmgr@ The distinctive feature of Poudriere is that it builds each port in a cleanest environment possible - a pristine FreeBSD base system and only needed dependencies. All other build tools around do not guarantee this, which might lead to build failures that do not happen in Poudriere. By "not supported" I mean that committers are not obliged to check whether a port can be compiled outside of Poudriere. Such a requirement doesn't even make sense since there might be myriads of different environment configurations and it is impossible to test them all. The "not supported" claim doesn't mean that portmaster or synth shouldn't be used, however. It doesn't even mean that patches fixing builds under these tools will be rejected. It just means that you're more "out of warranty" if something goes wrong and that you are expected to try and help yourself first. Going non-poudriere path requires you to be a "power user". I often find myself ignoring problem reports like "foo/bar does not build for me with all my custom setup", because it is extremely hard to reproduce the same environment that leads to a build failure. > is our make and our shell no longer a "supported" ports build tool? For a single-shot build - yes, it is the intended way. make is our engine, a lower-level tool that is utilized by a higher-level machinery. The thing is, the "building a port" goal isn't the same as "maintain an up-to-date package set". You can't reduce the latter problem to a series of a former ones. > my site has yet another such tool Just why you're reimplementing Poudriere? Poudriere serves as a golden standard on how to do all these seemingly easy but complex in reality tasks, like computing what has changed and what ports should be rebuilt. Synth, portmaster, portupgrade and your tool are essentially reimplement parts of Poudriere logic, but miss many corner cases and complexity and then ask the framework to adapt to your simple tools, like bumping PORTREVISIONs. Even you don't like something in Poudriere, then the way forward should be to extract common logic from it into a library that all other tools may use. > i only had to `service dbus restart` to unbreak a great many things. that may > have been what Martin was snagged by. i took me about a frustrating hour with > an oddly misbehaving system before it dawned on me lol First, bumps wouldn't help this issue. The service wouldn't be restarted anyways. Second, and most important - the pkg tool itself is also somewhat low-level. And using it again requires a user to be the "power user". Generally, upgrading some program is not safe while this program is running. A user should understand what he's updating and how to do that safely. Or call "pkg upgrade" from the single user mode to be on the safe side. One day we'll bring PackageKit support up to state where updating packages would happen during system's shutdown or startup sequence, like it is done in many other contemporary OSes. -- You are receiving this mail because: You are the assignee for the bug.
