Re: Nitpicking: you are doing it wrong
On 07/09/2011 10:30 PM, Leo costela Antunes wrote: [ lots of valid arguments ] I think you got me (at least partly) convince on the short dh style. However, I reamain convince that Jakub's point to not nitpicking new comers on the dh versus dh_* style is very valid. Thanks for the interesting thread. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1b23ab.6050...@debian.org
Re: Nitpicking: you are doing it wrong
* Leo costela Antunes cost...@debian.org [110708 23:41]: Please use dh/cdbs/whatever other means necessary to make your packaging work easy to read and understand. Don't make the packaging more complex for other people just because you want to know what's going on. But please also do not use anything you do not understand. I my eyes the normal dh_* scripts are a good middle ground in being high level enough to not hide the big picture in details while still being transparent enough to know what's going on. Especially having the calls to upstream's build system in such files explicitly listed makes it easy to check they are called the proper way. Using dh or cdbs means it needs quite some knowledge to be sure it is done right. You never know who might have to NMU it, make QA uploads, etc and even you yourself might find it pretty hard to remember why you did something in this particular fashion, when it actually could just as well be done in a more common way. In my experience with modifying packages locally cdbs and dh are quite a pain, as too many things are done automatically so that small changes can require quite a big diff. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110709110910.ga2...@pcpool00.mathematik.uni-freiburg.de
Re: Nitpicking: you are doing it wrong
On 07/09/2011 05:41 AM, Leo costela Antunes wrote: On 08/07/11 22:23, Thomas Goirand wrote: On 07/08/2011 08:47 PM, Scott Howard wrote: Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) I really would like you to explain WHERE you saw such a consensus. When it goes down to myself, I would *not* sponsor a package that is using either dh or CDBS, because I like to be in the control and see what's going on. I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion though, but I suspect that I might not be the only one to think this way. In anyways, I don't see at all a consensus here!!! Seeing what's going on is important for learning and for debugging. Thankfully debugging with dh is pretty mature, should you happen to need it (don't really know about cdbs), but having to read a non-dh-using rules file to understand exactly what happens when and why can be a lot of work and shouldn't be imposed on your fellow DDs if you don't have a good reason for it (curiosity and a micro-management tendency are not good reasons; funky non-standard build-systems are) Please use dh/cdbs/whatever other means necessary to make your packaging work easy to read and understand. Don't make the packaging more complex for other people just because you want to know what's going on. That sounds awfully like NIH[0]. You never know who might have to NMU it, make QA uploads, etc and even you yourself might find it pretty hard to remember why you did something in this particular fashion, when it actually could just as well be done in a more common way. Not using these tools goes against your own advice here[1]: you're making the life of other developers who have to look at your code harder for no reason. Or to put it more succinctly in your own words: otherwise, you have no rules at all and it's a mess. And your performance argument seems like a dud unless you can provide some evidence that you actually save a significant amount of time by not using dh/cdbs/whatever during package builds (and by significant I mean more than just a couple of seconds per build). Cheers If you are writing that using dh is more easy than using normal debhelper, then I don't agree, it's not always the case. I've seen many overly complicated packages with tons of dh_overwrite_* stuff, which makes the work flow very complicated and barely readable. I'm not bying into the legend that a dh using package is more easy to maintain. As for the performance, it's quite obvious that dh is doing so many useless debhelper calls. Just read what you see on screen. I hope you didn't miss-read me. I do push for using debhelper, but not dh, which I have reasons to dislike. One of the most obvious reason is that people are going to just rely on things they don't understand. It's hiding a complexity that people HAVE to understand. CDBS is even worth than dh in this regard. On 07/09/2011 07:09 PM, Bernhard R. Link wrote: But please also do not use anything you do not understand. I my eyes the normal dh_* scripts are a good middle ground in being high level enough to not hide the big picture in details while still being transparent enough to know what's going on. Especially having the calls to upstream's build system in such files explicitly listed makes it easy to check they are called the proper way. Using dh or cdbs means it needs quite some knowledge to be sure it is done right. Exactly!!! And while I'm not pushing you to like or use this type of packaging, I don't see why you should push me for another one. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e18414d.70...@debian.org
Re: Nitpicking: you are doing it wrong
On 07/09/2011 05:14 AM, Gergely Nagy wrote: I believe that when someone knows the underlying system, using helpers is the way to go, because it makes not only your task easier, it also makes it easier for others to understand the packaging. We were talking about mentoring, and you are talking about someone who knows the underlying system, and we should generalize and push them to use dh because of that. Isn't there is something wrong here? NMUing something with a complex, home-built debian/rules is a pain in the backside at best. Come on! It's not. Most debian/rules using debhelper (and not CDBS or dh) looks nearly the same, with very little tweaks. And yes, one does sacrifice a lot of control on the altar of convenience. But I don't see that as a problem, there's nothing wrong with convenience. And while useless helper scripts add to the build time, that load is negligible. Even on the slowest machine I could get my hands on (emulated armel, with ~256Mb memory, running on an dual-core amd64 host, along with 4 other VMs), the difference between using dh $@ and explicit dh_* commands on an average package was about 3 seconds. Completely getting rid of debhelper and doing everything by hand made it 2 more seconds faster. I don't know about you, but for 5 seconds, I'm not going to give up convenience. It really depends. If the package is really small, and if it takes 6 seconds in total to build, then skipping 5 seconds is a win. If it takes anyway 2 minutes, then yes, I don't care about 5 seconds. Then again, the beauty of Debian is that people are allowed to tailor their packaging to their own liking (as long as it conforms to policy... sadly a debian/rules written in SHOOP does not). There's arguments for and against both helper-using and helper-less packaging, neither is a silver bullet. My point to give arguments about not using dh was *not* to start a troll thread about what is best practices. It was simply to tell that there are some arguments for and against using dh, and as a consequence, I found very bad to write in this list that not using dh was a bad idea. People like different things, and using a helper like dh or CDBS should *not* be a requirement written in this list. For this, Jakub is 100% right. At best, this would be a sponsor requirement (and for sure, it wont be mine, which is only to not use CDBS which I don't understand). So don't take me wrong. I'm not vouching *against* dh, in some cases I agree it might be convenient, but just not always, and at the end, it's more a mater of preferences. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1843d4.7000...@debian.org
Re: Nitpicking: you are doing it wrong
Thomas Goirand z...@debian.org writes: On 07/09/2011 05:14 AM, Gergely Nagy wrote: I believe that when someone knows the underlying system, using helpers is the way to go, because it makes not only your task easier, it also makes it easier for others to understand the packaging. We were talking about mentoring, and you are talking about someone who knows the underlying system, and we should generalize and push them to use dh because of that. Isn't there is something wrong here? I thought we were talking about sponsoring. Which is not the same as mentoring. There are people who have good knowledge of debian package building, yet, are sponsored. But even if it's one's first package, I'd rather push them towards dh as a starting point, becuase that's _simple_. Getting to know the underlying system takes time, and when you expose a new contributor to that, he might very well run away. In short, one needs to find out on a case by case basis which would be better. I see no point pushing someone who already has 10+ packages in Debian towards dh7, when he'd much rather just be done with it and use dh8. On the other hand, when someone's obviously inexperienced, and makes silly mistakes, explaining that mistake, and suggesting to play with dh7 (or even helper less) to understand the system better might be a good approach. But neither fits all cases. NMUing something with a complex, home-built debian/rules is a pain in the backside at best. Come on! It's not. Most debian/rules using debhelper (and not CDBS or dh) looks nearly the same, with very little tweaks. Most dh7 packages look similar enough, yes. Those are the least of one's worries, though. Nor do these fall under the 'complex, home-built debian/rules' category. I don't know about you, but for 5 seconds, I'm not going to give up convenience. It really depends. If the package is really small, and if it takes 6 seconds in total to build, then skipping 5 seconds is a win. If it takes anyway 2 minutes, then yes, I don't care about 5 seconds. 5 seconds never matters. Ever. Not even if that 5 seconds is 90% of the build time. It won't stall the buildds, it won't make any difference at all. Then again, the beauty of Debian is that people are allowed to tailor their packaging to their own liking (as long as it conforms to policy... sadly a debian/rules written in SHOOP does not). There's arguments for and against both helper-using and helper-less packaging, neither is a silver bullet. My point to give arguments about not using dh was *not* to start a troll thread about what is best practices. It was simply to tell that there are some arguments for and against using dh, Agreed, there are arguments for and against dh. There's more for it than against it, though, and if one chooses to use dh, in the vast majority of cases, he shouldn't be discouraged, in my opinion. For this, Jakub is 100% right. At best, this would be a sponsor requirement (and for sure, it wont be mine, which is only to not use CDBS which I don't understand). So don't take me wrong. I'm not vouching *against* dh, in some cases I agree it might be convenient, but just not always, and at the end, it's more a mater of preferences. We seem to agree then, it's just our preferences lying on other sides of the fence ;) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyavboau@luthien.mhp
Re: Nitpicking: you are doing it wrong
On Fri, Jul 8, 2011 at 6:55 AM, Jakub Wilk jw...@debian.org wrote: Don't get me wrong, in my opinion (some of) these things are good. But making a big fuss about them is not helping anybody. It only distracts attention from things that are important, and creates false impression that they are somehow crucial for high quality packages. I can assure, they are not. Getting back to the original point for a second, I think that it has been shown that there are no right or wrong nitpicks (at least in the list that you posted.) I originally wasn't trying to post a reference implementation for sponsorship but just give examples and reasons as to why those nitpicks might not be wrong. Sponsors/DDs are well aware that there are multiple ways of handling a package for sponsorship. People asking for sponsorship are allowed to disagree with comments during a review, and being able to communicate the disagreement and work with a sponsor is a sign of maturity (someone that might be good to start the NM process.) One of the great things about sponsorship is that it is a case by case basis: each sponsor, sponsoree, and package has different levels of comfort, skill sets, and requirements. In some cases, the listed nitpicks are crucial for a high quality package, and in some cases they are, at best, an exercise in packaging (which, for many new contributors, may be quite useful.) At worst, to an experienced contributor, those nitpicks are a waste of time, but an experienced contributor should already have a good working relationship with a sponsor that wouldn't require all of that for an upload. A cold call request for sponsorship on -mentors will most likely have many nitpicks (some may even be contradictory: one sponsor may say no dh/cdbs while another may ask you to use dh/cdbs.) The requester's job is to take those reviews and work with their sponsor to do what's right for that package (and that sponsor.) Regards, Scott -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANg8-dBi2G=FzpW3UVnLSNOXwZLEqAGb5NCuHMVDJ0u=jm0...@mail.gmail.com
Re: Nitpicking: you are doing it wrong
On 09/07/11 13:53, Thomas Goirand wrote: If you are writing that using dh is more easy than using normal debhelper, then I don't agree, it's not always the case. I've seen many overly complicated packages with tons of dh_overwrite_* stuff, which makes the work flow very complicated and barely readable. You're missing the point again: of course you can make dh rules unreadable. The point is that it's easier to write *more* readable rules *most* of the time. Mind you: nobody ever said *always*. It's like Joey Hess mentioned in another mail in the thread: when used correctly, the override targets make it clearer where the package actually needed special treatment, which means I don't have to look for the proverbial needle in the haystack when reading a potentially big rules file; it's already explicitly there for me to see. I'm not bying into the legend that a dh using package is more easy to maintain. Legend? Maybe I'm reading too much into it, but it really sounds like you have an emotional grudge against dh. But we seem to be discussing two different and unrelated things here: 1) maintainability 2) understanding of the underlying system I say they're unrelated because it's irrelevant to the first point if the maintainer knows how a tool works as long as he knows how to use it to overcome possible problems and the end-package quality remains the same. I'll address the first point here and the second as a response a bit further down. What makes a package easier to maintain must be judged by the ease with which a different DD can make contributions to it, because the maintainer him/herself is way too used to the code to make objective observations (you probably remember why you used this or that, so it shouldn't seem complex to you). I also assume that starting from scratch, without any prejudice, it's *at least* as easy to learn to use dh_* helpers as dh short style (again: we're discussing just the first point here; no understanding necessary at this point). Now, all things being equal you want to do an NMU. If it's your average package with just one important but small detail, you might very well open the rules file, parse its ~100 lines, not see the detail, try to make whatever change you wanted to make, have it blow up in your face and finally go back to the rules file and read it more carefully. Why did you miss the detail? Because it's easier to miss something in ~100 lines of almost-always-identical code (where you skim more then read), than in 10 lines of code where the only thing is an override target telling you *exactly* what you should pay attention to. To make matters a bit worse, dh_* style encourages a bit of cruft: since the lines have to be there anyway, you have less incentive to clean up after yourself and remove arguments which aren't needed anymore (like old -X arguments for files that aren't installed anymore). This may not have any impact on the final package, but it adds up to the things people unfamiliar with the code will try to keep in mind, even if it's unimportant, making the job of understanding the rules file a bit harder. Of course these arguments highlight a *small* difference in maintainability and are in no way reason for me to go out screaming for people to re-upload everything with dh short style, but it's reason enough for a so inclined sponsor to ask potential sponsorees please use a shorter rules file where possible because I don't want to have to parse ~100 lines of almost-standard dh_* example code to make sure I'm not doing something stupid whenever I want to change something As for the performance, it's quite obvious that dh is doing so many useless debhelper calls. Just read what you see on screen. Yes, that's obvious, but does it cost you more than a couple of seconds per build? No. In that case, these mere seconds are more then worth it making a more readable package for your average DD. (again, I can't stress it enough: I'm not saying it's a one size fits all solution, but use it where it works). You make it sound like these extra dh_ calls have some impact besides irritating you on a pure quest for theoretical elegance level, which they don't. I hope you didn't miss-read me. I do push for using debhelper, but not dh, which I have reasons to dislike. One of the most obvious reason is that people are going to just rely on things they don't understand. It's hiding a complexity that people HAVE to understand. CDBS is even worth than dh in this regard. And here I address the second point mentioned earlier. This argument is also a dud. It's equally easy for a maintainer to use dh_* or dh short style without knowing what's going on underneath. I know I did this with dh_* almost 10 years ago. You can simply copy one of the example dh-make rules files and semi-blindly hack away at it until it compiles and generates a lintian-clean package. You don't automatically gain more knowledge about the system simply because you copied a template with
Re: Nitpicking: you are doing it wrong
On Sat, 09 Jul 2011, Thomas Goirand wrote: My point to give arguments about not using dh was *not* to start a troll thread about what is best practices. It was simply to tell that there are some arguments for and against using dh, and as a consequence, I found very bad to write in this list that not using dh was a bad idea. Not using dh for a new package is a bad idea IMO. Sure enough, you can do the packaging once without dh to force you to learn the commands and what's going on. That's fine. But then when you're doing the packaging that you want to submit to Debian, it's best to use dh because the package will be more maintainable on the long run (for all the good reasons that have already been given). I don't share at all the 2 arguments that you listed against dh: - performance is not a real problem, the few seconds of build time are neglible even for small package, 5 seconds more in a build doesn't change much compared to the time you have invested in creating the package - readability, I find the override very good to point out what's special in the package (you would not notice in a normal debhelper package that a dh_foo call has been moved in the list) Of course, it's not a requirement at the debian level. But that's not a good reason to not recommend it to newcomers. They don't have the required experience to know what's best for them. Thus we should point them towards something largely accepted and recommended. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110709190517.gd30...@rivendell.home.ouaza.com
Re: Nitpicking: you are doing it wrong
Le vendredi 8 juillet 2011 12:55:52, Jakub Wilk a écrit : [SNIP] Don't get me wrong, in my opinion (some of) these things are good. But making a big fuss about them is not helping anybody. It only distracts attention from things that are important, and creates false impression that they are somehow crucial for high quality packages. I can assure, they are not. Maybe these comments could be done in a seperate part of the mail. For example: * Below are nit-picking comments, feel free to ignore them, they are suggestions and may not even be suited to you ** // nit picking comments signature.asc Description: This is a digitally signed message part.
Re: Nitpicking: you are doing it wrong
On Fri, Jul 8, 2011 at 6:55 AM, Jakub Wilk jw...@debian.org wrote: Dear reviewers, next time if you are going to complain about: - debian/compat being too low; There are cases where it should be bumped [1], support for old versions gets removed. Many sponsors take the approach What should be done eventually must be done immediately. From the debhelper manpage [2] Unless otherwise indicated, all debhelper documentation assumes that you are using the most recent compatibility level, and in most cases does not indicate if the behavior is different in an earlier compatibility level, so if you are not using the most recent compatibility level, you're advised to read below for notes about what is different in earlier compatibility levels. and v8 This is the recommended mode of operation. You're right, it says recommended - not required, but sponsors will ask you to do every recommended, should, or --pedantic -I. - debian/rules not using dh (or not using cdbs); Some sponsors are only comfortable sponsoring dh or cdbs. You are free to do what ever you'd like (you can even write the rules file with no debhelper commands at all) but the sponsors are also free to ask you to change it to what they are comfortable with. You can always find a sponsor that is more comfortable with your style and work with them as well. Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) - debian/copyright not in DEP-5 format; This is accepted and will be policy soon [3]. What should be done eventually must be done immediately. - source format not 3.0 (quilt) when there are no patches whatsoever; 3.0 (quilt) doesn't just handle patches, it has other features as well [4]. Even if you aren't interested in those features, and even if you don't have patches, that doesn't mean the person who will NMU your package two years from now won't want to add a patch, and NMU's should be changing source formats. What should be done eventually must be done immediately. please think twice. Most likely, you are doing it wrong. You're right that none of these are serious problems in a package that would prevent it from being useful or in the archive, but neither are the lintian --pedantic or -I warnings that sponsors ask to have fixed. The sponsors are picky for a reason (namely to have complete, robust, and somewhat standardized packaging to make QA, NMUs, and long term maintenance easier,) if you don't like their approaches you are free to work closely with another sponsor. [1] http://lintian.debian.org/tags/package-uses-deprecated-debhelper-compat-version.html [2] http://manpages.debian.net/cgi-bin/man.cgi?query=debhelpersektion=7 [3] http://dep.debian.net/deps/dep5/ [4] http://wiki.debian.org/Projects/DebSrc3.0#Advantages_of_new_formats -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cang8-dabm3kfocgmbrtjnomq2ken1hpjhtj5ubmxjgyo3u2...@mail.gmail.com
Re: Nitpicking: you are doing it wrong
On Fri, Jul 8, 2011 at 6:55 AM, Jakub Wilk jw...@debian.org wrote: Don't get me wrong, in my opinion (some of) these things are good. But making a big fuss about them is not helping anybody. It only distracts attention from things that are important, and creates false impression that they are somehow crucial for high quality packages. I can assure, they are not. I appreciate your comments, and I believe the above sentence is the take away message Jakub wanted to get across. While nit-pickiness is not crucial for high quality packages, Debian has a culture of high technical quality to the point where we acheive near 100% bug free releases. This culture goes all the way to nit-picky packaging details at package creation. By the time you ask for sponsorship, the package is probably already in good shape. The mentors list is about have a couple extra pairs of eyeballs to go through and find those small things. It's like buying a house: yes there is a difference between a cracked foundation and a drippy faucet, but a home inspector wouldn't be doing their job if they didn't report the leaky faucet. (I, and many other sponsors, would consider the nitpicks you mentioned to be akin to a leaky faucet and not just a bad coat of paint since fixing them would make a more technically complete package.) Cheers, Scott -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cang8-darcvvuvrn5gr7fgs5tr5kcqyqh-18wbscvsjwqgw0...@mail.gmail.com
Re: Nitpicking: you are doing it wrong
On Fri, 8 Jul 2011 08:47:31 -0400, Scott Howard showard...@gmail.com wrote: - debian/copyright not in DEP-5 format; This is accepted and will be policy soon [3]. What should be done eventually must be done immediately. I think you might misunderstand the DEP process, which is easy to do. The following is my understanding. Accepted DEPs must still go through a policy revision process. The point is to converge on a process/implementation, and once that process/implementation becomes widely used and successful, then it can become policy. In particular, I would find it pretty surprising if DEP-5 became a policy must, and suspect that it will most likely be a policy may [1]. That would mean that not having a DEP-5 copyright file might, at some point in the future be grounds for a wishlist bug. David [1]: see http://www.debian.org/doc/debian-policy/ch-scope.html#s1.1 for definitions. pgpdyhadsIq1r.pgp Description: PGP signature
Re: Nitpicking: you are doing it wrong
On Fri, Jul 08, 2011 at 12:55 +0200, Jakub Wilk wrote: (I'm creating a new thread rather than replying to a particular message, because my mail is not at all personal. It's a general tendency amongst many debian-mentors reviewers that I'm going to rant about.) A sponsor on 2011-07-08, 11:22 wrote: 1. You're using debhelper compat 7 and also only debhelper = 7.0.50~ as Build-Depends. Please bump that to 8 Seriously? Is the sponsor suggesting that one should be build-depending on a newer version, even though one does not use any features of the newer one? Also, the sponsor failed to explain that normally upgrading debhelper compat is not a matter of bumping a number here and there. I can understand how this applies to older packages that have been created in the past and just don't use some of the new functionality, but I guess that the points are valid for completely new packages. I had the impression that it is desirable to create those in such a way that they use the latest compat, debhelper features and soon-to-be policy additions such as DEP5. That's a potentially time consuming and error-prone process. Creating a package for the first time is a time consuming process, but should one not target the current state of the art? Dear reviewers, next time if you are going to complain about: - debian/compat being too low; Are there specific reasons to choose a version lower than the recommended one for *new* packages? - debian/rules not using dh (or not using cdbs); If I were to sponsor packages I would at least like to see a justification why these have not been used. The decision not to use these helpers might be well-justified, but should be made explicit as the reasons not to use dh, for example, might mean that the helper is lacking functionality or behaves buggy in certain situations. - debian/copyright not in DEP-5 format; You have to create that file anyway for a new package, why not use DEP5? Don't get me wrong, in my opinion (some of) these things are good. But making a big fuss about them is not helping anybody. It only distracts attention from things that are important, and creates false impression that they are somehow crucial for high quality packages. I can assure, they are not. +1 IMHO the package creation phase is a very important step in the lifetime of a package and should target the state-of-the-art, as it lays the groundwork for everything that comes afterwards. Are there reasons not to focus on being up-to-date? Uploading a non-DEP5 package for example just means that the copyright has to be changed later in order to be policy compliant, doesn't it? -- .''`. Wolodja Wentlandbabi...@gmail.com : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Nitpicking: you are doing it wrong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2011 15:56, Wolodja Wentland wrote: 1. You're using debhelper compat 7 and also only debhelper = 7.0.50~ as Build-Depends. Please bump that to 8 Seriously? Is the sponsor suggesting that one should be build-depending on a newer version, even though one does not use any features of the newer one? Also, the sponsor failed to explain that normally upgrading debhelper compat is not a matter of bumping a number here and there. I can understand how this applies to older packages that have been created in the past and just don't use some of the new functionality, but I guess that the points are valid for completely new packages. I had the impression that it is desirable to create those in such a way that they use the latest compat, debhelper features and soon-to-be policy additions such as DEP5. Jakub, I'm with Wolodja on this regard. While I totally agree with your argumentation from a technical perspective, and I admit there are few (no, even) reasons to /insist/ on such things, there are still good reasons to suggest more state-of-the-art alternatives nonetheless. Its about the wording, granted this. Maybe the reviewer should be careful to say something like Consider upgrading ... or There is a newer compat level which is the currently recommended mode of operation but not literally Upgrade to compat 8, yours is wrong This is because I still think its wrong to introduce _new_ packages with older compatibility levels or older, but still policy compliant practices. This is why I regularly point this out when I encounter such packages and my sponsors did the very same with my packages. We have a lot of older legacy stuff in Debian which would not pass any RFS as of today, but this does not necessarily mean we should have this level for new packages as well. This is why I don't consider a bit of nitpicking wrong for new packages. Creating a package for the first time is a time consuming process, but should one not target the current state of the art? Seconded. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOFxTVAAoJEMcrUe6dgPNtzuUP/3oJJMDmGYOX7xxKYT3tmfBZ ZamjLau6mg2c1qxS08Xkfc/+ts077qXBH6ddb0oKuhq6Xk4ap9cE/1ynT09Qu/dY 5/Z5VBLyeKC3wN5gSiQw4sdd2ucUEG1bCxmmPse3IbGdhJG+w6qImRoDmj/N291J EKd6qMRIZ7nCgKMXexloDW2MOiBmxE7vdpeTWiH6M4WnFLYvVO96l+QgL4rdezym d+rgZRKUzNkU0l/foxqZkBSSI2AqOLEXYJLAzuTtPvZJgcWAT4V/M/SShTWZ6BMN R5mYiUoCW2Pbj0V5KglyNaP/1k/Ew64b8FFePOXeZFqTo9xaXkT/+daqEWyfX3gz mhDSb6ISJEuVdhOK9lFjv40b+fp5HuUkVQXLAlj57mb0DOLrZ2njJcmpVsTNonPX aC+AZgL9lBVqO4b/W4YY+bc7+2SgbDDxHWDgT1OwyFtU1ctOjG5T31rSyIQaX8J4 mB6JXO+0Eg4yHVY3a/MPghXD14pddhIF+e2/eQeKm7CB980FA+Dne9rwFhw6TMCG 6T6u7rT8AHJULZADTYRuGECpv2lXuVJbejrbVhg0uMIwzmk8H0R5I0vwRyBdKPb1 MTqztO/0HD/Ax2Zq7a8+e1nJMVL7Pwl6Q7TkVv0b66ac8TJqmT0p3YrREwQ+k3MI pZau905i54ydUbGXxsAc =pr6u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1714d5.3010...@toell.net
Re: Nitpicking: you are doing it wrong
Scott Howard showard...@gmail.com writes: On Fri, Jul 8, 2011 at 6:55 AM, Jakub Wilk jw...@debian.org wrote: - debian/copyright not in DEP-5 format; This is accepted and will be policy soon [3]. What should be done eventually must be done immediately. It will be in Policy and maintained via the Policy process, but it's an *optional* policy. No package will be required to use DEP-5. It won't even be at the should level. That was part of the original DEP-5 discussion; it's there for people who want to use it, but it's not something the project wants to standardize on. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uy0zr8v@windlord.stanford.edu
Re: Nitpicking: you are doing it wrong
On Fri, Jul 08, 2011 at 04:31:49PM +0200, Arno Töll wrote: On 08.07.2011 15:56, Wolodja Wentland wrote: I can understand how this applies to older packages that have been created in the past and just don't use some of the new functionality, but I guess that the points are valid for completely new packages. This is because I still think its wrong to introduce _new_ packages with older compatibility levels or older, but still policy compliant practices. This is why I regularly point this out when I encounter such packages and my sponsors did the very same with my packages. If you don't make use of newest shiniest features, higher debhelper levels just make backporting harder for no gain. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110708162430.ga26...@angband.pl
Re: Nitpicking: you are doing it wrong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Adam, On 08.07.2011 18:24, Adam Borowski wrote: If you don't make use of newest shiniest features, higher debhelper levels just make backporting harder for no gain. There is debhelper 8 in both, lenny-backports as well as in squeeze-backports. Moreover Debian packages target Sid, not (Old-) Stable, and this is where efforts should be invested in. Moreover backports are something optional, not a requirement for new packages, or something which should even necessarily kept in mind when working on packages. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOFzBzAAoJEMcrUe6dgPNtw04QAK4StDmMDYWY3uagFLPRBUGL fHvQp5GipJxKi4vEeOpahORncq1RicLhpgimBQrAK4u054qmogtppMvPhpDD7sei k2cUEIUEImn94KD1Mwdm8fc1BOhul8Enl2f82NJOkZZVSlYsJM7W9AWJAjiEEBa2 6ioCdDEJZkuUHZL9iM9n8VIcM0dcbp/w+j0srmoQJPImkVLbsaI9VLojdtW9plPo wrC+tvxzbuOcQMSL1nGaPSB+Y1nZ3hHcmvuvXtql8xLea2mZ4hoH5N0ZDYGzqfzX H86rbRa5jwlr875n1C4cybUn/aMIqZQHZ7aZOFNBbd0vN4PraaCOv190bNSok7e0 EpfMi0DdQbvNxn+H9Jl+SoKpBXdkTchpBLqmKYOpbJ6w+8ecfK39R2X9HnVQDw54 7gVEB0alP7+pKfY758OQIxIwPOgjWXfFueZqbeRJ7DVg122ZkAMVEtA4zT5t/5fg 11ei6ZVGyjwQs95Ml8zlh/UkYz4LINuLKN/g2Uw0C1bfY3VWhUhF5OzZKNdMRlhQ /QS7uwGrvsy2Wm7Owo2GBLf3SVyd4Luzpx2zZj8HDNIh+QGbsXG0Xdj9Wce9spMC swFEedTE1DNjWrBAAwtXrZzv+QgenKMJK34XNY3NLdVQvDZlsudOppX1StFPWV9C FqTcpgzWBNd2GM9qQqdz =H3Ov -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e173073.9070...@toell.net
Re: Nitpicking: you are doing it wrong
Hi Jakub, hi all, [...] (whether or not to request bumping debhelper compat; I do agree with the technical arguments put forward by Jakub, but that's not the focus of my reply) The obvious provocative answer is: Nitpicking is the way to go. As always, however, there's more than black and white out there. Dear reviewers, next time if you are going to complain about: - debian/compat being too low; - debian/rules not using dh (or not using cdbs); - debian/copyright not in DEP-5 format; - source format not 3.0 (quilt) when there are no patches whatsoever; please think twice. Most likely, you are doing it wrong. Don't get me wrong, in my opinion (some of) these things are good. But making a big fuss about them is not helping anybody. It only distracts attention from things that are important, and creates false impression that they are somehow crucial for high quality packages. I can assure, they are not. I tend to agree that mentioning such potential-but-not-required improvements may distract from major problems. Yet, speaking for myself, I try to only put those points forward whenever they could also help to fix more serious issues. I'm trying to use these rules (in the order of the above list): - If debian/rules is overly complicated, and thus either known to be broken or at least likely to contain errors, I'll suggest going for dh 7 simplified format. - If debian/copyright is clearly missing information, or does not state sufficiently clearly the copyright holders and license information, I'll suggest DEP-5. This is almost always true whenever the code uses more than one license or copyright holder. - Source format 3.0 if quilt is manually invoked. All of the above points are about maintaining minimal packaging standards. If that's called nitpicking then, well, so be it. To me, however, package sponsorship and nitpicking do go well together: 1. Likely there won't be any review as detailed as the one before sponsoring a package for the first time. Nitpicking: now or never. 2. Consistent nitpicking yields consistent minimal package quality (yes, it's not necessarily good quality, but it's consistent). 3. Unwillingness to sponsor a package that only fails those non-essential tests (nitpicking) does not mean a package would be rejected. It's just about finding another sponsor. Especially the comments about debian/rules not using dh or cdbs: if a sponsor feels uncomfortable with the packager's debian/rules it's clearly preferable that the package not be sponsored by this particular reviewer. In summary: there are technical arguments against increasing dh compat level - agreed. debian/rules: to be left to the reviewer's discretion. debian/copyright: I'm in favour of DEP-5 for added clarity, which is particularly important when it comes to licensing and copyright issues. Best, Michael pgptmZWKJgAVB.pgp Description: PGP signature
Re: Nitpicking: you are doing it wrong
Hi, Nice topic, thanks to Jakub for having the good idea to have started it. On 07/08/2011 08:47 PM, Scott Howard wrote: Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) With all the due respect... I really would like you to explain WHERE you saw such a consensus. When it goes down to myself, I would *not* sponsor a package that is using either dh or CDBS, because I like to be in the control and see what's going on. I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion though, but I suspect that I might not be the only one to think this way. In anyways, I don't see at all a consensus here!!! - source format not 3.0 (quilt) when there are no patches whatsoever; 3.0 (quilt) doesn't just handle patches, it has other features as well [4]. Even if you aren't interested in those features, and even if you don't have patches, that doesn't mean the person who will NMU your package two years from now won't want to add a patch, and NMU's should be changing source formats. What should be done eventually must be done immediately. Again, this is a preference. I don't like format 3.0 (quilt), and these days, I'm sticking to 1.0 because I like it, and I don't think anyone has the rights to tell me otherwise. A debate about these is a waste of time, please don't start it and let everyone choose what he likes. You're right that none of these are serious problems in a package that would prevent it from being useful or in the archive, but neither are the lintian --pedantic or -I warnings that sponsors ask to have fixed. The sponsors are picky for a reason (namely to have complete, robust, and somewhat standardized packaging to make QA, NMUs, and long term maintenance easier,) if you don't like their approaches you are free to work closely with another sponsor. That, I agree, and everyone should. So please do not state your own preferences as being the reference implementation. Thomas Goirand (zigo) P.S: Appart from above, I'm a strong supporter of DEP5, because otherwise, you have no rules at all and it's a mess. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e176729.8070...@debian.org
Re: Nitpicking: you are doing it wrong
On Fri, Jul 08, 2011 at 12:55 +0200, Jakub Wilk wrote: [...] but should be made explicit as the reasons not to use dh, for example, might mean that the helper is lacking functionality or behaves buggy in certain situations. I don't get it here... Do you think that debian/rules calling the emacs debhelper when it's not needed 99.% of the times is a superior way to do packaging? Or is using something fully automated where you don't have to think or understand what's going on a better way to do things? In what way not using dh has to be justified at all? I'd rather say the opposite way! I really don't think that dh is state-of-the-art (as Arno is saying later on in this thread). Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e17691e.9070...@debian.org
Re: Nitpicking: you are doing it wrong
Hi Adam, On 08.07.2011 18:24, Adam Borowski wrote: If you don't make use of newest shiniest features, higher debhelper levels just make backporting harder for no gain. There is debhelper 8 in both, lenny-backports as well as in squeeze-backports. Moreover Debian packages target Sid, not (Old-) Stable, and this is where efforts should be invested in. Moreover backports are something optional, not a requirement for new packages, or something which should even necessarily kept in mind when working on packages. While I agree with your argument of debhelper being present in lenny and squeeze backport, I think it is the only one. I strongly do not agree with the or something which should even necessarily kept in mind part. Giving an advice here or there to have backporting made more easy doesn't hurt. It's not a strong requirement, but it for sure is a good thing. If you (build)-depend with (= version) being unecessary too high, you are unecessarily making the life of the eventual backporter harder, and this should be avoided if possible. When I do a sponsoring, it might not be very common to do so, but I always try the package in both Stable and SID, to see if there are eventual issues that may raise. Sometimes, a few minor tweaks here or there really helps to make the backport being reduced to a diff in debian/changelog. That doesn't only help an eventual backporter, but also anyone which is running Stable, and wishes to rebuild a SID package for his own use (which I do often for myself). Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e176b0d.8060...@debian.org
Re: Nitpicking: you are doing it wrong
Thomas Goirand z...@debian.org writes: On Fri, Jul 08, 2011 at 12:55 +0200, Jakub Wilk wrote: [...] but should be made explicit as the reasons not to use dh, for example, might mean that the helper is lacking functionality or behaves buggy in certain situations. I don't get it here... Do you think that debian/rules calling the emacs debhelper when it's not needed 99.% of the times is a superior way to do packaging? Or is using something fully automated where you don't have to think or understand what's going on a better way to do things? In what way not using dh has to be justified at all? I'd rather say the opposite way! I really don't think that dh is state-of-the-art (as Arno is saying later on in this thread). As someone who was very strongly against helpers in the past[0], please allow me to chime in. I do agree that whoever is packaging a piece of software needs to understand how the system works underneath. However, once that is understood, I now see no harm in using dh: I know what it will be doing, and that extra ~5 seconds spent calling helpers that do nothing is something I couldn't care less about. I much more prefer a ~6 line debian/rules, that works now, and thanks to the helpers, will very likely work a year from now, without me having to change it, because the helpers will adapt the package to current policy. One still needs to verify that the result is what one expects, but it's much easier to verify, than to migrate AND verify aswell. We have tools to serve us, let the tools do that! Or we can go out and build debs with tar and ar. (I actually had an applicant in the past who suprised me with a package that did just that. ;) Personally, I find dh to be very neat, and useful, as it allows me to keep my rules very short. Comparing my current packages to the ones I made a decade ago, the new ones are much easier to understand and update. I recently had a look at an old package of mine.. it was a mess. Two pages of gory, uninteresting, perfectly common commands instead of two lines of this: %: dh $@ I believe that when someone knows the underlying system, using helpers is the way to go, because it makes not only your task easier, it also makes it easier for others to understand the packaging. NMUing something with a complex, home-built debian/rules is a pain in the backside at best. And yes, one does sacrifice a lot of control on the altar of convenience. But I don't see that as a problem, there's nothing wrong with convenience. And while useless helper scripts add to the build time, that load is negligible. Even on the slowest machine I could get my hands on (emulated armel, with ~256Mb memory, running on an dual-core amd64 host, along with 4 other VMs), the difference between using dh $@ and explicit dh_* commands on an average package was about 3 seconds. Completely getting rid of debhelper and doing everything by hand made it 2 more seconds faster. I don't know about you, but for 5 seconds, I'm not going to give up convenience. There's also the case where the assumptions made by the helper tools work against the packager's wishes, and at that point, when the tools start to get in one's way, they should be either fixed, or dropped. When the effort spent on workarounds start to approach the time saved by the tools, it's time to reevaluate, and perhaps drop the helpers. But until then, why? Then again, the beauty of Debian is that people are allowed to tailor their packaging to their own liking (as long as it conforms to policy... sadly a debian/rules written in SHOOP does not). There's arguments for and against both helper-using and helper-less packaging, neither is a silver bullet. 0: http://lists.debian.org/debian-newmaint/2001/10/msg00021.html -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739iglbjm@luthien.mhp
Re: Nitpicking: you are doing it wrong
On 08/07/11 22:23, Thomas Goirand wrote: On 07/08/2011 08:47 PM, Scott Howard wrote: Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) I really would like you to explain WHERE you saw such a consensus. When it goes down to myself, I would *not* sponsor a package that is using either dh or CDBS, because I like to be in the control and see what's going on. I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion though, but I suspect that I might not be the only one to think this way. In anyways, I don't see at all a consensus here!!! Seeing what's going on is important for learning and for debugging. Thankfully debugging with dh is pretty mature, should you happen to need it (don't really know about cdbs), but having to read a non-dh-using rules file to understand exactly what happens when and why can be a lot of work and shouldn't be imposed on your fellow DDs if you don't have a good reason for it (curiosity and a micro-management tendency are not good reasons; funky non-standard build-systems are) Please use dh/cdbs/whatever other means necessary to make your packaging work easy to read and understand. Don't make the packaging more complex for other people just because you want to know what's going on. That sounds awfully like NIH[0]. You never know who might have to NMU it, make QA uploads, etc and even you yourself might find it pretty hard to remember why you did something in this particular fashion, when it actually could just as well be done in a more common way. Not using these tools goes against your own advice here[1]: you're making the life of other developers who have to look at your code harder for no reason. Or to put it more succinctly in your own words: otherwise, you have no rules at all and it's a mess. And your performance argument seems like a dud unless you can provide some evidence that you actually save a significant amount of time by not using dh/cdbs/whatever during package builds (and by significant I mean more than just a couple of seconds per build). Cheers [0] http://en.wikipedia.org/wiki/Not_Invented_Here [1] http://lists.debian.org/msgid-search/4e176b0d.8060...@debian.org -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iv7thn$faq$1...@dough.gmane.org
Re: Nitpicking: you are doing it wrong
On 07/08/2011 12:29 PM, Arno Töll wrote: On 08.07.2011 18:24, Adam Borowski wrote: If you don't make use of newest shiniest features, higher debhelper levels just make backporting harder for no gain. There is debhelper 8 in both, lenny-backports as well as in squeeze-backports. There's no debhelper 8 in Ubuntu Lucid and earlier, though. (FYI, debhelper 8 is already in Squeeze, you don't need bpo) Moreover Debian packages target Sid, not (Old-) Stable, and this is where efforts should be invested in. Moreover backports are something optional, not a requirement for new packages, or something which should even necessarily kept in mind when working on packages. I disagree strongly on the latter. I try to be kind to backporters, even to deriviatives (eg, regarding Lucid above: I don't even use Ubuntu), so unless there is a compelling reason to use compat level 8, I'll stick to 7. The above of course can be generalized to any package, and simplified to unless there is a compelling reason to require version $BAR, I'll stick to $FOO -- which I believe is only common sense. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: Nitpicking: you are doing it wrong
On Saturday, July 09, 2011 12:41:09 AM Leo costela Antunes wrote: On 08/07/11 22:23, Thomas Goirand wrote: On 07/08/2011 08:47 PM, Scott Howard wrote: Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) I really would like you to explain WHERE you saw such a consensus. When it goes down to myself, I would *not* sponsor a package that is using either dh or CDBS, because I like to be in the control and see what's going on. I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion though, but I suspect that I might not be the only one to think this way. In anyways, I don't see at all a consensus here!!! Seeing what's going on is important for learning and for debugging. Thankfully debugging with dh is pretty mature, should you happen to need it (don't really know about cdbs), but having to read a non-dh-using rules file to understand exactly what happens when and why can be a lot of work and shouldn't be imposed on your fellow DDs if you don't have a good reason for it (curiosity and a micro-management tendency are not good reasons; funky non-standard build-systems are) Please use dh/cdbs/whatever other means necessary to make your packaging work easy to read and understand. Don't make the packaging more complex for other people just because you want to know what's going on. That sounds awfully like NIH[0]. You never know who might have to NMU it, make QA uploads, etc and even you yourself might find it pretty hard to remember why you did something in this particular fashion, when it actually could just as well be done in a more common way. Not using these tools goes against your own advice here[1]: you're making the life of other developers who have to look at your code harder for no reason. Or to put it more succinctly in your own words: otherwise, you have no rules at all and it's a mess. And your performance argument seems like a dud unless you can provide some evidence that you actually save a significant amount of time by not using dh/cdbs/whatever during package builds (and by significant I mean more than just a couple of seconds per build). + a debhelperized use pattern, for performing common tasks, is very likely to be way more robust than a 200 lines of (self-tested) NIH thing, simply because thousand of people using/testing it. It is about re-use of well tested code, a lot of wisdom has been accumulated and implanted during the years. + If we were to live with the old concepts and old patterns, which might have been valid a decade ago, then there would be no progress and inventions at all. Debhelper is the perfect compromise (as design) and a giant step upward (as implementation). Cheers [0] http://en.wikipedia.org/wiki/Not_Invented_Here [1] http://lists.debian.org/msgid-search/4e176b0d.8060...@debian.org -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107090111.23445.danc...@spnet.net
Re: Nitpicking: you are doing it wrong
On Sat, Jul 09, 2011 at 04:23:05AM +0800, Thomas Goirand wrote: On 07/08/2011 08:47 PM, Scott Howard wrote: Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) With all the due respect... I really would like you to explain WHERE you saw such a consensus. When it goes down to myself, I would *not* sponsor a package that is using either dh or CDBS, because I like to be in the control and see what's going on. I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion though, but I suspect that I might not be the only one to think this way. In anyways, I don't see at all a consensus here!!! I'd like to give a concrete example of why I have changed my opinion from perferring control to preferring dh/cdbs. Consider the recent discussion on -policy and -ctte about changing dpkg-buildpackage (and policy) to use the build-arch and build-indep targets in debian/rules. These are currently optional, so many packages don't provide them. If you use cdbs, you get full support for these rules for free, in that cdbs will provide them for you. If you use a recent debhelper, dh also provides them for you. This means that as and when dpkg-buildpackage and policy change to requiring these targets, over half the archive can switch to using them with *zero changes required*. Conversely, the packages which chose to do things by hand require *manual changes* to add support. That's over 8000 packages, and a lot of essentially pointless make-work, since it could quite easily be automated. This is just one example. By not hard-coding the list of dh_ helpers being called, it means that your package will automatically use any new helpers without any manual source changes. And as the helpers are updated to match policy, your package stays compliant with current policy. I think that due to the massive size of Debian, we do need to consider that making even a small change is often difficult, not because it's intrinsically complex, but because of the huge amount of manual work required to complete it. By using helpers such as dh, many things become trivial to change, archive wide, with nothing more than a binNMU. So from the POV of the distribution as a whole, helpers do provide a tangible and significant benefit. I would argue that not using a helper unnecessarily increases the maintenance burden we all shoulder, and that we should actively encourage further adoption of dh and cdbs. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Nitpicking: you are doing it wrong
Scott Howard wrote: From the debhelper manpage Unless otherwise indicated, all debhelper documentation assumes that you are using the most recent compatibility level, and in most cases does not indicate if the behavior is different in an earlier compatibility level, so if you are not using the most recent compatibility level, you're advised to read below for notes about what is different in earlier compatibility levels. This is overstated; while it's quite likely the documentation for a particular command will fail to mention some change made in a recent compat level, the compat level is always mentioned when some incompatible change or new feature is actually properly documented. :P and v8 This is the recommended mode of operation. This qualification is there mostly to avoid people using v9 before it's complete; the only non-recommended compat levels are v4 and below, which are deprecated. As a point of comparison, the compat histogram for packages I co-maintain is: 124 7 6 5 3 8 2 4 1 9 1 6 Thomas Goirand wrote: I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Bear in mind that CPUs have doubled in speed something like 7 times since debhelper was originally written -- and it was written from the beginning to be not annoyingly slow when every command was put in the rules file. There have also been some siginficant speed improvements made for the dh case. A rules file for a multiarch packages using dh is likely to be faster than one hand-written. I suspect this may come down to phycology at this point; we see a lot of commands running and feel the build took longer. Of course there is still room for improvement -- it's been suggested that dh could run many commands in parallel.. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion To the contrary, I find that it exposes the essence of what makes a package different, and even an example such as the following does not seem hard to read, because there are no complex interrelationships between the override targets. override_dh_auto_install: $(MAKE) prefix=`pwd`/debian/debconf-utils install-utils $(MAKE) prefix=`pwd`/debian/debconf-i18n install-i18n $(MAKE) prefix=`pwd`/debian/debconf install-rest # Run dh_link earlier so that it has an opportunity to link documentation # directories. override_dh_installdocs: dh_link dh_installdocs override_dh_installdebconf: # Don't modify postrm, I purge differently than normal packages # using me dh_installdebconf -n override_dh_install: dh_install cp debian/apt.conf debian/debconf/etc/apt/apt.conf.d/70debconf cp bash_completion debian/debconf/etc/bash_completion.d/debconf override_dh_installchangelogs: # Changelog reduction hack for debconf. Only include top 100 entries. perl -ne '$$c++ if /^debconf /; last if $$c 100 ; print $$_' \ debian/changelog debian/debconf.changelog dh_installchangelogs override_dh_compress: dh_compress -X demo.templates -X tutorial.templates -- see shy jo signature.asc Description: Digital signature
