Wouter Verhelst <wou...@debian.org> writes: > On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote: >> Wouter Verhelst <wou...@debian.org> writes: >> >> > On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: >> >> Dmitrijs Ledkovs wrote on his blog[0]: >> >> >> >> >Generally if software is useful in Debian Project it can be useful >> >> >for other debian-like and unlike projects. In particular native >> >> >packages do not offer the same patching flexibility as 3.0 >> >> >(quilt), thus forcing downstream distributions to inline modify >> >> >packages without DEP-3 headers. This hurts us, when trying to >> >> >merge useful stuff from derivatives back into Debian, as changes >> >> >are not split into individual patches. >> >> >> >> I would tend to agree that we have too many native packages, >> > >> > There can only be "too many" of anything if it is (or can be) harmful in >> > some way to have the thing in question. >> >> Perhaps not a convincing argument, but one of the main reasons I >> mightily dislike native packages for things that aren't Debian specific >> in any way, is because it sets a bad example. If you see native packages >> being abused for the sake of convenience, > > Doing something for the sake of convenience is not a bad thing. On the > contrary; inconvenience is (terribly) bad for motivation and > productivity.
Doing something for the sake of convenience is not, in itself, a bad thing indeed. Even with native packages, if you know what you're doing, and you're careful, you're not doing any harm, either. However, that's you, with a ton of experience behind your back, and deep knowledge of Debian. Then someone comes along, looking for examples, and sees a growing number of native packages: "Oh hey, this is easy, I'll do this too!" And things go downhill from there. There *are* cases where native packages are inappropriate, and it is already a pain in the backside at times to convince people new to Debian that native packages do have unwelcome properties in certain cases. My belief is that Debian packages should not only be technically sound (which a lot of them already are), but should also set a good example for those who are looking for inspiration, for ideas. It is a bit more work for the packager, yes, but I've yet to see a case where the extra work would not be trivially scriptable to the point that one only needs to remember a command or two - which is, as far as I'm concerned, far below the annoying threshold. (I know counter examples must exist, but for the general case, I doubt that the debian-upstream split would be all that hard, not even in the long run.) >> it becomes that much easier to give in to temptation, and use native >> packaging even when it does have harmful side-effects. > > That's a recursive argument: You're trying to convince me that doing > something is bad simply because doing it may cause us to do it more. But > if I don't think that "doing it more" is a problem any more than doing > that something in the first place is, you've not actually convinced > me. Imagine gcc or the linux kernel being native packages then. >> By harmful side effects, I mean two things: >> >> - Awkward to NMU > > As I said in my previous mail, that's indeed a bug that should be > fixed. Easily fixable by making the package non-native. >> - Patches not separated > > That's not a bug; it can be a feature, and even when it's not it can be > argued that it's not a terrible issue. Packages should be in SCM, and > you should have some form of communication with people who package work > with your code. If you don't, you have a bigger problem than whether or > not you're using native packages. That's a terribly sweet idea, but in practice, it doesn't work. If it would, I'd be the happiest person on earth. First of all, not all downstreams use an SCM (shocking, I know), and not all of them keep them up to date, especially if their SCM is located elsewhere than upstream's. I've seen both NMUs and downstream packages which were supposed to be in SCM, but the SCM was out of date. I'd love to trust downstream SCMs, but experience shows that rarely works, and my most stable point is whatever they have in their archive - and that's the Debian source package. I'd love if downstream talked to me directly, and sometimes they do, sometimes their SCM is even up-to-date, but most of the time, we talk in patches (which is also good, but what patches they send me, and what is in their archive often differs, as some patches are deemed 'unimportant' or 'irrelevant' for Debian - which they may be, but let me decide that, thankyouvermuch). In summary, yes, I have bigger problems than native packages, and that sucks, but native packages add insult to injury, because even if communication fails, I have a hard time inspecting what they do, because I lack the nicely separated patches. >> While separating patches is often seen as an inconvenience, a useless >> one at that in the world of SCMs, it does reduce the amount of space >> needed to store the result, it makes it easier to review the difference >> between two versions. Granted, one can look at the SCM repository, but >> there are times when that's far more work than paging through a set of >> diffs: ie, comparing two versions of a Debian package. If there are >> diffs, that's easy. > > If there aren't diffs, running debdiff isn't hard. ...except it is useless if the diff contains multiple independent changes, and I have to separate them manually. Been there, done that, wasn't fun. > It's true that if the code has diverged a lot, figuring out the > individual, separate changes that are applied to the original code can > be a hard job. However, before that becomes a problem, the code itself > needs to be sufficiently large (it's pretty hard to lose track of the > changes made to a package containing a single script of, say, a few > hundred lines of code). Yep, that is true. But small packages are the least of my worries. See below, though, some of the things I explain there applies even to things that are only a few hundred lines of code. > As I said before, I'm not advocating that you would maintain a > sufficiently large codebase as a native package. So in the situations > that I think native packages make sense, this isn't actually an issue. ...except that it sets a bad example (see above), and makes it harder to convince people who do want to maintain a larger code base, to not do it as a native package. "But XYZ is doing it, with a much larger codebase! IT WORKS!" Perhaps it is just me, but I'd like to think that my packages are of good quality, and that they can serve as good examples (or in rare cases [hi, shoop! I miss you <3], as terrifying ones). I'm ready to sacrifice the minor convenience native packaging would buy me, so that those who have to work with my packages downstream, or those who look at them for inspiration, will find it easier to work with them. I like to think this is worth the effort. So far, the sacrifices made have been minor, usually only as much as debian/source/git-patches file (for gitpkg) and a git checkout debian && git merge master from time to time. >> > While I agree that in some cases it might be a bad idea to package >> > something as a native package, for trivial things (like my package >> > "fdpowermon"), this isn't a big deal; and the overhead of having to deal >> > with an upstream tarball and/or upstream build system etc is just not >> > worth it. >> >> 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. > > It's not just about creating it, but also about it not being worth it. See above. It may not seem worthy to you, but for downstream, or for other people working with your package, it very well may be. It's not only about you, in my opinion. I for one, when I'm acting as downstream (which sadly I sometimes I have to, either when I'm backporting something, or when I do stuff for $work), hate having to work with native packages. It's inconvenient at best, and downright painful when it's not even using an SCM. But even when an SCM is used, merging is more painful when it needs be: I usually get both upstream and debian packaging patches, even when I'm interested only in the former. Having to manually separate the two is more work for me. > Well, if you're not doing an upstream build system, then you're not > providing anything beyond your Debian package. The net result is that > you're not doing anything that couldn't be done by way of a native > package too, while lying to potential non-Debian downstreams that you're > considering their use case too. There are cases where an upstream build system is completely unnecessary: when there's nothing to build, and all you need to install can easily be done with debian/install. That does not mean I'm not considering downstream's use cases, it just means that an upstream build system is not necessary. (Take for example git-flow, which does have an upstream build system, but it's almost completely pointless) If I'd do all building things that one normally does with auto* in debian/rules, now THAT would be silly. > If you don't have an upstream build system, you only have a package. If > you only have a package, it should be a native package, and not have a > non-functional upstream tarball, because that is evil. If your software does not need a build system, there's little point in trying to add one. There are software you do not need to build, and the only thing you need is put various parts of it onto $PATH somewhere. I wouldn't write a full blown build system for that. -- |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/87r4l447q3.fsf@algernon.balabit