Philip Hands <p...@hands.com> writes: > Gergely Nagy <alger...@balabit.hu> writes: > ... >> We have tools that make it easy to create upstream tarballs from an SCM >> repo. Git has git archive, gitpkg and possibly other tools make it very >> easy to create upstream tarballs: so much so, that it means nothing more >> than tagging the repo properly. >> >> I've been using this for quite a while for some of my packages (ivykis, >> libmongo-client), and it doesn't need neither an upstream build system, >> nor much thought once it is set up. (And setup is fairly trivial too) > > So to summarise your argument appears to be that it sets a bad example > (which is only a valid criticism if you manage to show why it's a bad > idea in the first place) and that you don't like people not using all > the same tools you use.
No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. Exceptions exist, and three cheers for them! Only if they weren't the exceptions... > If the person doing the packaging is the upstream, you're asking them to > pretend to be two people, and decide when a patch is debian specific or > not, and then learn a load of tools that they have no use for in order > to keep their personality neatly split. If the change is under debian/, then it is debian specific, otherwise it is not. That's a reasonable rule of thumb, and doing just this would entirely satisfy me. Doesn't need a personality split, in my opinion. There's also the case where upstream and debian maintainer are the same *now*, but that can change anytime. Case in point: there's a package[1] in Debian where upstream & maintainer used to be the same, but not anymore. Nevertheless, for hysterical reasons, upstream is still shipping a debian/ dir, an outdated and crappy one, which, from time to time, still confuses the hell out of people who download the original tarball. That sucks. It's an upstream problem, but it wouldn't have happend in the first place, if packaging & upstream work weren't tied together so tightly in the past. [1]: syslog-ng Anyway, I'll expand on this later, see the end of my mail. > I know a couple of upstreams who use native packages for their stuff, > and I'm pretty sure one or both of them would give up if we insisted > that they add unnecessary and confusing extra steps to their workflow. What steps would be confusing? > Currently they just incorporate the debian directory into their tree, add > a couple of steps to their release Makefile target, and whenever they > release a new version, it's ready for Debian too. Instead of adding a few steps to my release target, I have a script that checks out the debian branch, merges master, and dch -i. It's about 5 lines long, and pretty much the same thing as a Makefile target. I could also wire it into a release target, if I had one. It's neither confusing, nor any extra work, apart from about 5 minutes spent on thinking about the workflow, once. > You're going to have to do a lot better than saying that you don't like > it very much if you're going to convince me that Joey's mistaken in that > choice -- particularly since he comes up with pretty decent arguments in > the opposite direction -- see his answer here: > > > http://ask.debian.net/questions/does-native-package-needs-to-be-debian-specific-if-upstrean-author-is-a-mantainer I don't want to convince you that Joey is mistaken, for he is not. There's nothing inherently wrong with native packages, and there are plenty of cases where they make sense (I maintain two native packages myself, there's no possible way to convince me they should be made non-native), Joey has strong arguments for him handling his packages native, and I agree with him on that. But the same arguments don't hold for everyone. > Certainly there seems to have been no acknowledgement that there are > good examples available that break that rule. I beg to differ: http://lists.debian.org/debian-devel/2013/01/msg00588.html Perhaps I should've phrased it differently, but I believe my message there was quite clear nevertheless. > On the other hand, it's pretty obvious that one will be able to point to > examples where the package clearly should not be native, but that > doesn't tell one much about the general case -- this thread seems to > boil down to: > Look, here's a bad thing, therefore all things are bad. I don't know where you got that from. Most of us posting in this thread have expressed that native packages aren't the problem, their abuse is. In my reading, it boils down to: "Look, here's a bad thing, and bad things are spreading. Lets stop the bad things." Granted, we didn't really explain what that "abuse" is, so let me try to do that! * In my opinion, a native package is always a wrong choice when upstream and debian maintainer are not the same. This is still the case if the debian maintainer is part of upstream, but is not the sole upstream. I hope I don't need to explain this further. * In my opinion, a native package is the wrong choice when your only arguments for it is convenience. That's not a strong argument, and we can most probably list a bunch of counter arguments: * Makes it harder for downstreams to patch (Have to figure out a version number, and hope it won't conflict, etc. It is also harder to separate downstream patches from upstream, VCS doesn't always help [esp. when they're stale]) * Makes NMUs more awkward There are probably other cases where I'd consider native packages a wrong choice, but off the top of my head, I could only list this two. If so need be, I'll spend a few more brain cycles on digging up the rest. There are good arguments *for* a native package, as Joey listed, and they can work well if upstream == maintainer. But as soon as that relationship breaks, for whatever reason, care needs to be taken both upstream and both in packaging to ensure a smooth transition. I've seen that fail before, though, not with native packages. When trying to avoid downstream forks, when trying to maintain strong control over the package, a native package can also work fairly well. But these two are the only reasons I can find that support native packages, they're a good fit in these cases. But using them out of sheer laziness, having no better reason that convenience? That's weak, and that's what *I* would like to see disappear. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obg95uqw.fsf@algernon.balabit
