Skip to content
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

Open
MTecknology opened this issue Apr 25, 2017 · 11 comments
Open

Support pbuilder #11

MTecknology opened this issue Apr 25, 2017 · 11 comments

Comments

@MTecknology
Copy link

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.

@stapelberg
Copy link
Contributor

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)

@MTecknology
Copy link
Author

Why would supporting pbuilder not be a good idea?

@stapelberg
Copy link
Contributor

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.

@onlyjob
Copy link

onlyjob commented May 21, 2017

Personally I like pbuilder more than sbuild...

@stapelberg
Copy link
Contributor

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?

@MTecknology
Copy link
Author

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.

@stapelberg
Copy link
Contributor

However, I personally found package injection with pbuilder to be significantly easier than with sbuild

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 sbuild --extra-package=/path/to/package.deb. The last time I used pbuilder, one had to create a local repository, then add that, then update it regularly.

Shouldn't there be more interest in supporting various tools and workflows than forcing one preference on everyone?

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.

You know where that leads...

No. Where does it lead to, in your opinion?

I find sbuild to be very clunky and painful to work with

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.

@zhsj
Copy link
Member

zhsj commented Sep 5, 2017

Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801053 here, so we can track if pbuilder is easy to inject deb yet.

@onlyjob
Copy link

onlyjob commented Jul 30, 2018

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. --login is to enter chroot); chroot is stored in a tarball and building in different suites is straightforward if not trivial. pbuilder's configuration file is in HOME; building in tmpfs is simple, using ccache is simple; build is offline which is a big plus. IMHO pbuilder is not to be underestimated and I've found it far easier to use (with assistance of pdebuild command) than under-documented schroot/sbuild.

@stapelberg
Copy link
Contributor

I’m not keen on adding and supporting a significantly different code path just to support pbuilder.

If a similar interface to sbuild’s --extra-package could be added to pbuilder, I’d be open to accepting a pull request which makes the builder configurable.

@rolandmas
Copy link

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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants