On Sun, Aug 16, 1998 at 12:17:45PM -0500, Manoj Srivastava wrote: > I am biased about this, so my rationale might not be the best > thing to look for. But the bottom line is that you should do what is > right for you, and the majority of people start out by using > debhelper or equivalent. I'm going to add my comments (as a fairly new maintainer) all around. I use debhelper because IMO it makes the debian/rules file more readable but I've found places it doesn't work so well and I have to resort to some pretty ugly hacks to put things in place for some of the nastier of packages I've looked at and played with. > Helper Package (debhelper) Advantages > i) These make it easier for novices to package things. There si > knowledge built into the scripts, and it may be easier to let > the helper package do the arcane tasks While this is true of debstd, it's not really true of debhelper as much. You still have to know enough about the package and the packaging format to put the right debhelper commands in the right place, and not every situation has a premade command. Some of those arcane tasks may be better done by hand so you understand how to do them. Perhaps if you already understand them, it may be better for you to use debhelper because it's easier to let it take the grunt work out of packaging. This is certainly a matter of taste. > ii) If mainatined, they keep fairly good track of policy, and > changes to policy may be handled merely by upgrading the helper > package and rebuilding one package Of course, if NOT maintained, debhelper could end up like debstd, which is kinda behind on policy. If you used debstd before and wanted to move to debhelper now, you're going to have a time doing it. They are different enough that there is no simple upgrade, though there is a method of returning the list of debhelper commands to that would do approximately what debstd would do in the same circumstances, but what it returns needs much pruning. > Disadvantages: > i) One becomes dependent on them, and does not know what is going > on This was the case with debstd, but with debhelper you know what the rules file is doing because it does only what you tell it to. It's not one magic program that does everything but a series of smaller scripts that do different things. It's very easy to go from debhelper to roll-your-own and vice-versa. This wasn't the case with debstd. > ii) I, and a number of other people, find helper packages to be > less flexible than desired for complex packages; and a number > of people have left the helper package umbrella after gaining > some experience. (To be fair: lots of other people stick to > helper packages all through) With debhelper, you can do something by hand if it's better done by hand or yourself if it's better done by yourself. It allows mixing of debhelper and your own commands pretty easily. > iii) Bugs in helper packages affect ones package, and one has little > control over the time for the fx (Joey has been wonderful so > far) > iv) On has to learn the helper package, and what the commands do, > this is akin to learning a restricted language (I porefer > sticking to Perl, C, C++, java, sh, etc, which are usefl > elsewhere as well what does dh_man do[if there is a dh_man]?) The bugs issue and seperate commands issue can be problematic, but debhelper's commands are easy to learn fortunately and the package is updated frequently. > v) packages using helper packages depend on the version of the > helper package installed on the machine they are built on. So > your package may be built broken on a machine with an old > helper package version (and not build on machines like my > machines, since I do not install helper packages at all) This is actually more a flaw in Debian's source package format than anything. There is currently no method in practice (several in design as I understand it) for determining what is required to build a package as the maintainer designed. We've all been bitten by this once or twice I'm sure. > Doing ones own rules: > Advantages: > i) It is easier to get things right, since one does not have to > consider all possible packages all the time Easier to get it right if you know how to get it right. If you DON'T know all of that, you're in for some trouble because you'll have to learn how to do it right first. => That may not be such a bad thing of course, but it's still an issue for those who haven't much spare time since Debian is in most cases worked on in developers' spare time. > ii) One can exercise precise control, and can be more flexible > iii) One gets to know Debian policy rather well These are definate plusses, other than perhaps that there's a high margin for being left behind on policy versions. > iv) one can clone rules files and get most of the benefits of the > helper packages over time (my rules files are highly > standardized, really, with about 3-4 templates to choose from) > v) It is more satisfying for some people, like me These two don't really count. iv is the same for both methods and v is your opinion.. => > Disadvantages: > i) You have to know exactly what to do (this is not as bad as it > appears, since that is how we all did it before debmake) Again, is this such a bad thing? Perhaps this is how it should be. > ii) You have to keep track of policy, and change all your rules > files when policy changes At the same time, you should be keeping track of policy anyway, right? > iii) More prone to making errors (human error) than a script is Human errors happen. There's not much you can do about it. The human errors that can happen in the roll your own rules so easily can as easily happen in the debhelper package. Ever release a version of a package with a "stupid error"? Lots of people have. We're only (mostly) human aren't we? > I, in my inimitably biased fashion, prefer to think my rules > as hand crafting package, rather than a cookie cutter approach ;-) debhelper is less a cookie cutter approach than debstd was. What you use depends totally on what is best for you, you're the maintainer after all. Both are very viable solutions and as I said, you can convert between them easily. I've tried to play devil's advocate here and question all points. Perhaps between your comments and my responses, people might be able to make an informed decision. Or perhaps, someone may have further comments. I certainly welcome any that anyone may have.
Attachment:
pgpwEU36_8LG6.pgp
Description: PGP signature