-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support pbuilder #11
Comments
I’m not sure that’s a good idea. I’d prefer it if we could further sbuild (see also https://bugs.debian.org/859867) |
Why would supporting pbuilder not be a good idea? |
Philosophically: Because Debian tools are already too complex, and adding support for another tool without any clear benefits will only make that worse, not better. If pbuilder has any advantages over sbuild, we should improve sbuild instead. Technically: I originally tried building ratt with pbuilder, which I used at the time, and couldn’t get the package injection to work properly. When I saw how easy it was with sbuild, I switched to sbuild and haven’t looked back. |
Personally I like pbuilder more than sbuild... |
Is there any technical reason for that, or is it just being used to pbuilder at this point? |
If there's a real technical limitation to including support for pbuilder, then I can fully understand that position. However, I personally found package injection with pbuilder to be significantly easier than with sbuild. When I looked through the source, it seemed like it would actually be quite easy to support. Debating sbuild vs. pbuilder seems silly and I don't believe it should even be relevant. Shouldn't there be more interest in supporting various tools and workflows than forcing one preference on everyone? You know where that leads... If you really want the opinion, though... I find sbuild to be very clunky and painful to work with. Ease of injecting packages is one of the reasons I prefer pbuilder. It is a very subjective opinion. |
As you made the exact opposite experience that I made, now I’m curious: can you show the command-line you’ve used please? For sbuild, the command is
I don’t follow. As a tool maintainer, the more options we add, the harder maintenance becomes. Also, the more options there are, there more mental complexity we impose on our users. It is definitely in my direct interest to keep the tool as simple as possible.
No. Where does it lead to, in your opinion?
What are the pain points, specifically? Note that setup will be way easier once my patch (available on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859867) is merged. |
Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801053 here, so we can track if pbuilder is easy to inject deb yet. |
I'm not sure how to separate technical preferences from personal ones. pbuilder is an awesome tool, easy to use with container-like semantics (e.g. |
I’m not keen on adding and supporting a significantly different code path just to support pbuilder. If a similar interface to sbuild’s |
I'd like to chime in on the "support pbuilder" feature request, since I too find it easier to use and customize (the hooks system is awesome); however, maybe just adding support for a custom build command in ratt would be simple enough to implement and generic enough to be able to call pbuilder (or a wrapper script)? |
It doesn't look like it should be a very large change to support pbuilider/cowbuilder. To be honest, I'd never once touched sbuilder until I was trying to use ratt. For now, I'm going to learn a little about sbuilder, but in the long-term, I want to make ratt also support pbuilder.
The text was updated successfully, but these errors were encountered: