[transcript] source package formats
[ This is a transcript of a conversation on the Debian developer irc
channel. Note that Diziet is Ian Jackson. This transcript has been edited
for clarity and to remove other simulantaneous conversations. ]
<Overfiend> since both you dpkg guys are here.
<Overfiend> Can I ask for something? How about a flag in the .dsc that tells dpkg-source not to untar the .orig?
<wichert> rmt: you do NOT mail unsuspecing people 4Mb of stuff
<Overfiend> That would help with pristine source packages and dbs-type stuff
<wichert> Overfiend: how about a new source format?
<Overfiend> wichert: as long as it lets me do what I want
<seeS> Is this correct?
<wichert> Overfiend: okay. now give me 48-hour days and lots of money and I'll make it happen
<Overfiend> wichert: bah.
<Overfiend> I asked for what I did because I'd like to see it in woody
<Overfiend> a new source format, I won't see in woody :)
<rcw> Overfiend: wichert and guy have had a new dsc format cooking for at least a year
<Diziet> Surely the problem is that dpkg-source trusts the .tar.gz less than the untarred original source ?
<wichert> rcw: oh? we do?
<rcw> wichert: I certainly remember reading something about it about 6 months ago
<Diziet> If when you did dpkg-source --build it should include the original .tar.gz.
<Overfiend> Diziet: eh? I just want to delay the untarring of the upstream tarball until the rules file is run
<Diziet> Or does it not do that already ?
<rcw> wichert: maybe it wasn't you
<wichert> rcw: that might be klee's stuff
<Overfiend> rcw: besides, Guy hasn't been SEEN for at least a year :-/
<wichert> he already did that
<Overfiend> he and Brian White cancelled each other out about the time of glider's fuckup of the slink archive
<Diziet> overfiend: I don't understand. The .orig.tar.gz nees to be untarred and patched before the debian/rules exists. Are you talking about at unpack time ?
<rcw> Overfiend: details
<Overfiend> Diziet: no, it doesn't, and in fact we have several packages that don't do it that way
<Overfiend> Diziet: sendmail, glibc, xfree86, ...
<Diziet> overfiend: What ?? I'm very confused now.
<Diziet> overfiend: The debian/rules is in the .diff.gz, right ?
<Overfiend> Diziet: the "orig.tar.gz" just contains another tarball in a subdirectory
<Joey> Diziet, these pkg's use redhat type style
<Joey> Diziet: orig.tgz contains an orig, and diffs that a applied during debian/rules
<wichert> what I'ld like is a .dsc that lists one or more .orig.tar.gz's, and a tar of debian/ which can include patches
<Overfiend> The .diff.gz's for these packages are basically just tar'ed up debian/ dirs masquerading as diffs
<Diziet> Wergh, I've just unpacked the sendmail dsc and it's well weird.
<Overfiend> wichert: aye
<rcw> diziet: grab the gnome-napster source package and let doogie's dbs system soak into your head. it's a trip
<wichert> and debian/rules or something else can apply those patches at buildtime, no need to clutter the rest with that
<Overfiend> rcw: no, don't tell him that
<Culus_> rcw: Better than, say, acid? :P
<Overfiend> diziet will corner doogie and demoralize him out of the project :-P
<rcw> Culus: much better, and cheaper
<Overfiend> like he tried to do with Culus for writing in C++ :)
<rcw> Culus: plus every time you look at it you get a bigger trip, it's addicting
<Diziet> overfiend: This package is totally fucked. I can't edit the source and then dpkg-source --build it !
<wichert> I've also decided that conditional patches are probably the wrong approach
* Overfiend notes that the number of compiler warnings in X has not appreciably decreased from 3.3.6 to 4.0
<Overfiend> diziet: what package?
<Diziet> sendmail
<Overfiend> ah
<Diziet> I can't even _read_ the source without executing debian/rules.
<Overfiend> diziet: well, no, you can't, because people abuse the shit out of that system and cause monolithic patches
<Overfiend> diziet: like when I inherited XFree86
<Diziet> overfiend: Err, wot ?
<Overfiend> diziet: 500k of patches, not separated by function or anything else
<Diziet> What do you mean by monolithic patches ?
<Overfiend> a nightmare to deal with
<Overfiend> diziet: duh. .diff.gz
<Overfiend> it has debian/ + all patches to upstream rolled into one
<Diziet> That's what a version control system is for, right ?
<Overfiend> diziet: you can lead developers to cvs but you can't make them commit
<Diziet> Why do the X packages have such a large .diff.gz ?
<netgod> Overfiend: heh
<Overfiend> diziet: you get a snowball effect of acculumating, unrelated patches
<Overfiend> diziet: because we patch the shit out of it
<Diziet> Well, if they don't like having a single .diff.gz like that then they should use CVS. Making packages that people can't edit is not helpful !
<nick> Overfiend: do you edit diff files?
<Diziet> overfiend: 500K?! That takes some coding !
<Overfiend> diziet: oh well, I'll let you and wichert duke this out, what he proposed will make me happy
<Diziet> wichert: What are you proposing ?
<Overfiend> diziet: we didn't originate most of them, we just assimilated them
<Culus_> wichert: What now?
<Overfiend> diziet: a lot of it is SPARC support patches that XFree86 wouldn't let in for (apparently) political reasons
<rcw> wichert never clearly said what he was proposing :)
<Diziet> I see. In which case we don't need to edit them, is that right ?
<Overfiend> Diziet: except when upstream revs and we have to resync them, generally, yes
<Overfiend> Diziet: that very process was what drove me to dbs
<Overfiend> Diziet: it was colossal pain to resync the monolithic .diff against new upstream versions
<Diziet> of: So you should have designed and help write a new source format, not shipped broken packages ...
<Overfiend> Diziet: there is only so much time in the day, man. Trust me, maintaining X fills my plate adequately
<Diziet> of: Well, yes, but you shouldn't do a wrong thing because you don't have effort to do a right thing.
<Culus_> Overfiend: And doogie is working on bigger and better things
<Overfiend> Diziet: it will be easy to move a "right way" when one is available
<dhd> SRPM!
* dhd runs
<Diziet> of: So what you really want is a way to say that the upstream source is actually made by combining possibly more than one .tar.gz with possibly some `upstream' diffs too ?
<Overfiend> it's one line of shell to apply all the patches, and one more to say "make me a monolithic diff"
<Overfiend> then I'm back to the traditional way
<Overfiend> Diziet: no, but that would be good too, and was something doogie was looking into
<Overfiend> Diziet: in fact, we do have support for upstream patches, after a fashion
<Overfiend> it is inelegant but it works
<Diziet> of: Please tell me how to inspect the source code that our sendmail binaries are built from without executing the package.
<wichert> how is an upstream patch different from a debian patch in this regard?
<Diziet> (by executing the package I mean doing something with the source package that would allow a malicious source package to take over my account)
<BlindMan> wichert: i will try :)
<Overfiend> Diziet: untar the orig, cd in a few dirs and untar the real tarball
<Diziet> wichert: We never want to edit an upstream patch.
<Overfiend> Diziet: I don't know where sendmail keeps the real thing, I can only speak with confidence about XFree86
<Diziet> It's important that each Debian package has a single source tree when you've unpacked it, not a sort of ensemble of different ones.
<wichert> Diziet: that's a technicality though
<nick> Diziet: you could inspect debia/rules first
<Diziet> That way when you edit it everyone else alwas sees your edits if they use the package you build.
<Diziet> of: OK, tell me how to do that with X.
<Overfiend> Diziet: my edits aren't hidden. Unpack the package and look in debian/patches
<nick> What about a single diff format, but with a way to tag the diff's components?
<BlindMan> wichert: oh, yes *hmpf*
<nick> so you can esaily decompose the diff into separate diffs...
<Overfiend> Diziet: apt-get source xfree86-1; cd xfree86-1-3.3.6/upstream/archives; tar xfz X336src-1.tgz
<Overfiend> Diziet: of course, the debian/rules file unpacks the tgz into the conventional location
<Diziet> of: No, tell me how I can see the source code file which contains (say) main() in xterm ?
<Overfiend> Diziet: I'm just telling you how to get at the upstream pristine tarball
<Diziet> Ie, I mean the source file that the xterm binary in the .deb was built from.
<Overfiend> Diziet: before or after the upstream tarball is untarred?
<Overfiend> actually, it isn't untarred to the conventional locations
<xtifr> yeah, that's why I decided not to use dbs
<Diziet> of: Yes, I can tell that's what you're telling me. But what I want to know is how to find xterm.c (or whatever). If you want to read dpkg's main.c you can go dpkg-source -x .../dpkg*.dsc and then cd into dpkg-*/main and less it.
<Overfiend> Diziet: all right. after dpkg-source -x, cd xfree86-1-3.3.6; debian/rules source.unpack; find build-tree -name "xterm.c"
<Diziet> OK, I see now from tar zvvtf that it's called xterm/main.c. Please tell me how I can view the source that my xterm binary is run from.
<Overfiend> Diziet: what?
<Diziet> I've just done dpkg-source -x xfree86-something.dsc, and now I see:
<Diziet> -davenant:xfree86-1-3.3.6> ls -l
<Diziet> total 5
<Diziet> drwxrwsr-x 29 ian ian 4096 Mar 19 22:54 debian/
<Diziet> drwxr-sr-x 3 ian ian 1024 Jan 10 03:59 upstream/
<Diziet> -davenant:xfree86-1-3.3.6>
<Overfiend> Diziet: at this point, you do not see the source files as debian compiles them
<Overfiend> they have to be patched first
<Diziet> Tell me how to see the source code .../xterm/main.c _which will be used to compile an xterm binary for a .deb_, and _without needing to trust the source package_.
<xtifr> Diziet: debian/rules source.unpack
<Overfiend> (well, not EVERY file is patched...)
<Diziet> of: Yes, I know that.
<Overfiend> xtifr: no
<Overfiend> debian/rules source.make
<Diziet> xtifr: But debian/rules might contain
<Overfiend> that applies the patches as well
<Diziet> source.unpack:
<nick> Diziet: inspect debian/rules
<Diziet> sudo rm -rf /
<Overfiend> and we're protected against trojans in rules files now how?
<xtifr> yeah, like I said, all this is why I decided not to use dbs... :)
<wichert> Diziet: imho we should have dpkg-something that grabs things from debian/patches and applies/undoes patches..
<rcw> overfiend: we're not, but *unpacking* should stay safe
<Diziet> overfiend: No, not if we _build_ the package. But we can _look_ at the source code without trusting the rules file.
<Overfiend> Diziet: jeez, man, I don't have the upstream tarball encrypted
<Overfiend> so untar it
<Overfiend> everything's written in shell
<wichert> I've been thinking of reserving debian/dpkg-state or so to put things like substvars, files, and patch-status in
<Culus_> wichert: Maybe we should just use src.rpms :P
<Diziet> wichert: That would be a new source code format. Probably the contents of debian/patches should be outside the .orig.tar.gz and listed in the .dsc instead.
<wichert> Diziet: right. I'm thinking of tar'ing debian/
<Overfiend> Diziet: makefiles are written for convenience, not to obfuscate a procedure. You want to apply the patches by hand without using the rules file, you can
<xtifr> I think a <package>.diff.tar.gz instead of just <package>.diff.gz might be good
<Diziet> of: I've just looked at debian/rules and the string `source.unpack' only occurs here:
<Diziet> stampdir_targets+=source.build source.unpack fix.source.patch source.patch
<rcw> wichert: that'd be great
<Overfiend> Diziet: doogie tucks his dbs internal crap into another file, see debian/scripts/
<Overfiend> or, uh
<Overfiend> sys-build.mk
<Overfiend> I think
<wichert> Diziet: and have dpkg-source do a sanity to make sure that after undoing everything in debian/patches you end up with the exact same source as in the .orig.tars
* Culus_ watches the complexity explode
<xtifr> wouldn't <package>.diff.tar.gz solve most of these problems?
<Overfiend> diziet: I am defending my needs, not my practice
<Diziet> of: Now I could obviously spend an hour figuring out what the debian/rules does so I could trust it, or figure out what it did, or I could just assume it does something with debian/patches and try to do that by hand.
<wichert> xtifr: no, just debian.tar.gz is better since it means we also won't need to mess around with uuencoded stuff anymore
<xtifr> wichert: ah, yes, good point
<Overfiend> Diziet: well, there's a learning curve for everything
<Overfiend> Diziet: even dselect :-P
<Culus_> wichert: It would be more in the style of things to use ar's :>
<Diziet> xtifr: The diffs should be _separately listed_ in the .dsc so that the .dsc contains the md5sums of the diffs - this is useful because the .diffs if they are upstream might have widely-known md5sums.
<bma> <Overfiend> dselect is what happens when you tell a mathematician to
<bma> design a user interface
<bma> OF: *g*
<Diziet> of: So you agree your practice is wrong ?
<Overfiend> diziet: great idea
<Culus_> Diziet: And packages could then have a thousand seperate files
<Diziet> bma: I'm not a mathematician :-).
<bma> Diziet: I didn't make the quote
<rcw> culus: so? it's better that way
<Diziet> culus: Well, a dozen or two, perhaps, yes. (The names would have to be in some standard format)
<bma> I just stored it :)
<Overfiend> diziet: I'm sorry you're so offended by dbs, but I've said multiple times in this conversation that I have source packaging needs that aren't met by the canonical system
<wichert> Diziet: hmm.
<Culus_> Overfiend: How many patches do you have?
* bma has been moving stuff away from DBS
<Overfiend> Culus: uh...something like 80?
<xtifr> Diziet: sure, but the dsc could be stored in <package>.debian.tar.gz along with the patches and such
<wichert> Diziet: that would mean that you want the .dsc to lists entries that are inside a .tar?
<Overfiend> lemme check
<Culus_> There you go, 80 patch files, a .debian file and what? 5 upstream files?
<xtifr> we could reduce the number of files in our source format by one
<Overfiend> Culus: 96
<Overfiend> 1 upstream file
<Culus_> Okay, do X would be composed of over a hundred files
<Culus_> Overfiend: I thought X had several tars?
<Overfiend> actually, 3.3.6-3 includes three upstream "fixes"
<Overfiend> Culus: I have 3 source packages, one for each upstream tarball, RTFXSF, I've been doing it this way for 1.5 years
<xtifr> wichert: put the .dsc in the tar with the patches...
<xtifr> then it can have the md5 sums no prob
<Culus_> Overfiend: Oh you do now?
<Overfiend> Culus: this is news to you? Haven't you noticed there's not a new xbooks every time there's a new X server package?
<Culus_> Overfiend: *shrug* I don't download X every week to see what you are doing
<Overfiend> james noticed it right away, and was in fact an advocate of the practice
<Culus_> james would since he probably added your new source packages
<wichert> Overfiend: of course, it reduced the buildtime on m68k drastically I bet :)
<Overfiend> he thought the hit on the mirrors was excessive, shipping unchanged fonts and massive collections of PostScript every time some little tweak happened to the X binaries
<Overfiend> wichert: I don't have any figures from that far back, but probably, yes
<Culus_> I remember bitching about that too
<Diziet> of: So fix the canonical system, don't do something broken.
<Overfiend> since the upstream tarballs are not split arbitrarily, it was easy to do
<Overfiend> Diziet: sorry, if I touched your beloved dpkg code you'd bite my head off :-/
<Overfiend> besides, I don't have a clear idea for a correct solution
<Diziet> wichert: No, I want the other upstream diffs to be downloaded separately.
<wichert> Diziet: you realize how many seperate files you might get then?
<Overfiend> it seems that intelligent, experienced developers can have differing approaches to this...after all, you and wichert are discussing it, you didn't both automatically reach the same obvious conclusion
<Diziet> Perhaps if some packages are so large they should get a directory on the FTP sites. But having the diffs go separately makes a lot of sense for lots of purposes.
<Diziet> Not just md5sums visible, but also (eg) mirroring.
<wichert> the mirror-hit for a tar of all patches is minimal though
<wichert> I'm thinking of management issues with lots of different files
<Diziet> of: It's wichert's code now :-).
<Overfiend> diziet: well, you don't see HIM reaming me out. I've always known that dbs was a suboptimal solution. But for a long time little development was done on dpkg at all
<Diziet> of: Well, the right thing to do would be to have a discussion as to what was the right idea (on debian-dpkg perhaps) and then implement it.
<wichert> Diziet: are you going to zap all dpkg-iwj bugs someday?
<Diziet> w: err, yes :-). RSN :-).
<Overfiend> Diziet: the most I can offer is what I'd like to be able to do given my experience packaging X for two years
<Diziet> of: Right.
<Overfiend> Diziet: I don't have any particular passions about the mechanisms used to get there
<Overfiend> (well, I know better what I *don't* like, e.g., .src.rpm-type stuff)
<Diziet> wichert: I suppose we could put all the .diffs in a separate .diff.tar.gz and then put the md5sums in the dsc. I still think that the md5sums should be in the dsc so that you can use md5sum and gpg/pgp to verify the checksums against upstream checksums
<Diziet> - without having to unpack the .tar.gz.
<Diziet> of: BTW, I'm not reaming you out.
<wichert> Diziet: which means tar up debian/, and list all patches in debian/patches/upstream/* in the .dsc or so
<Culus_> Diziet: That issue seems to be entirely seperate. We should really be distributing any sort of upstream signatures along with our packages
<Diziet> of: We're all technical people here, right ? I'm not shouting at you. If I wanted to ream you out I'd say something like DEBMAKE IS EVIL :-).
<wichert> stu: so stop bitching and buy yourself a new disk
<Overfiend> Diziet: telling me to go fix this big design issue in dpkg instead of trying to get my job done with X feels like it. (BTW, I agree about debmake :) )
<wichert> Diziet: it is, but that's not overfiends fault :)
<Overfiend> Diziet: our XFree86 packages *still* have a record-breaking bug list, despite my efforts
<wichert> Overfiend: nonono, I have more open bugs then you do
<stu> overfiend: have you looked at the way the freebsd people handle XF86?
<Overfiend> wichert: you do? I thought your dpkg efforts kicked me into first place long ago
<Diziet> wichert: No, I think that dpkg-source -x shouldn't produce debian/patches. If the patches are logically outside the source tree - ie, you don't edit them directly, they shouldn't be in the package-version/ tree at all. They can just sit in the
<Diziet> .diff.tar.gz file.
<Diziet> of: I appreciate your efforts.
<Overfiend> diziet: what happened to being able to dpkg-source -x; cd; dpkg-buildpackage ?
<wichert> Overfiend: dpkg attracts bugs like honey attracts flies
<Overfiend> wichert: so does X :-P
<Diziet> of: I'm just a purist, you see. This is a philosophical difference: you're from the BSD school (do BALGE with what's available), and I'm with the MIT school (do it right, and if that means rewrite the universe first then so be it).
<wichert> Diziet: I think I'm not following you entirely here
<Diziet> The BSD people always get things released earlier, but they're never as good except when the MIT people never get a release out at all :-).
<Overfiend> Diziet: the MIT philosophy appeals to me, but I have a large sense of responsibility about X
<Diziet> w: OK, so conceptually we have this:
<xtifr> wishes the BSD fans form werk were here listening to this :)
<Diziet> w: The Debian package is an upstream + a Debian diff. We (Debian) only ever edit the Debian diff.
<Diziet> w: But we choose _which_ upstream to use, obviously.
<Diziet> w: At the moment an upstream is just a .tar.gz.
<Diziet> w: But, some upstream packages are, ahm, somewhat less well organised :-).
<wichert> right, with you so far
<Diziet> w: For example the tar doesn't unpack into the right place, or we want to apply lots of other diffs.
<wichert> right
<Diziet> w: The latter one is the thing we're talking about now.
<wichert> or multiple tars to be extractedin different places even
<Diziet> w: Quite.
<Diziet> OK, so when we dpkg-source -x something we expect to get a directory containing editable source code. It's like unpacking a tar archive - except
<wichert> so far we're following exactly what klee already did btw
<Overfiend> (BTW, the X upstream tarballs unpack into xc/, not into something like package-major.minor)
<Diziet> that we leave the upstreams lying about, because when we --build it we want to just regenerate the Debian diff and not any of the other stuff.
<Culus_> wichert: Klees thing was all weird and complex
<Diziet> w: So clearly the upstream patches are part of the upstream source, and shouldn't appear in the unpacked source tree at all.
<Diziet> w: So what we end up with is upstream = { tarfile+, diff* }
<Diziet> and debiansource = { upstream, debiandiff }
<Diziet> unpack means turn debiansource into unpackedsourcetree (and possibly copy upstream into current dir)
<wichert> Diziet: hmm
<wichert> Diziet: okay, I see that
<wichert> Diziet: I'm wondering how one would add something to that
<wichert> Diziet: ie upstream adds a new tar or patch
<wichert> Diziet: how do we add that to an already extracted source?
<wichert> bah, modem died, had to reconnect
<Diziet> pack means turn edited debiansource back into debiandiff (or, to look at it another way, turn { unpackedsource, upstream } into debiansource.
<doogie> Diziet: why not have multiple debian diffs as well?
<Diziet> w: I think you should edit the .dsc.
<Diziet> Before you extract it, that is.
<Overfiend> speak of the devil
<Overfiend> doogie: I need the latest dbs, please
<doogie> Overfiend: look at xawtv
<wichert> Diziet: meaning you need to unpack the whole thing again...
<Overfiend> doogie: don'tcha have a tarball someplace? I am lazy
<Diziet> Probably the .dsc you used would have to be copied into debian/ somewhere so you know how to rebuild.
<wichert> Diziet: I'ld like to be able to have multiple debian diffs as well
<wichert> Diziet: makes it easier to split things out and merge them with upstream
<Diziet> w: Why do you want multiple Debian diffs ?
<Diziet> w: I see. Hmm.
<Overfiend> yeah, for instance, not all of my 96 patches to X *need* to go upstream
<Diziet> The problem I see is this: if we have multiple Debian diffs, which diff are you editing when you edit the unpacked source ?
<Overfiend> some of them are just Debianizations
* netgod thinks theres something wrong with Diziet's clients' nick completion
<doogie> Diziet: I have a patch system, that supports multiple upstream tarballs, multiple upstream patches, and multiple debian diffs.
<Overfiend> doogie: QUIET! HE WILL DESTROY YOU
<doogie> netgod: he needs to enter more than a single char for bitchx to match.
<Diziet> doogie: We're just discussing that. I'm afraid I don't like it very much.
<wichert> Diziet: I'm thinking of having a simple file which lists which patches have been applied, and a tool to create a new diff with extra changes
<Diziet> doogie: Since of already thought I was reaming him out I'll try to be, erm, gentle :-).
<doogie> Diziet: well, my system is in use in 25+ pkgs, including apache, x, and pam
<xtifr> use cvs, kick everyone that doesn't use cvs out of the project, problem solved :)
<netgod> its a kludge, but the feature isnt in dpkg proper
<Overfiend> doogie: yeah, I was just telling him *why* I used dbs and my ass is still bleeding
<Diziet> w: Aha.
<wichert> doogie: afaik x has moved slightly away from your system
<netgod> its not like theres a choice
<doogie> Diziet: and a similiar system is in use for gcc and glibc
<doogie> wichert: no it hasn't.
<doogie> wichert: x had the very first version. the other pkgs have moved away from x.
<Diziet> doogie: Perhaps you can answer this rhetorical question for me.
<Overfiend> wichert: yeah, I'm using some antiquated prototype of dbs
<Overfiend> wichert: I pounded on it a little bit myself, too
<doogie> so far, I have the most used and most tested multi-patch system.
<Diziet> doogie: I have my local mirror here which has the sendmail dsc etc. Now I've just unpacked it and ...
<Overfiend> here we go
* Diziet is going to be deliberately naive here ...
* Overfiend now knows what it was like to be cowering in the London Underground during the Blitz
* joeyh notes that if you combine dbs and yada, you can get truely impossible to comprehend source packages. :-p
<Diziet> ... I want to read the source file sendmail/main.c.
<xtifr> give each patch a separate branch in cvs, then if you want to edit a particular patch, you just checkout that branch
<doogie> yada?
<doogie> Diziet: known problem.
<Diziet> But, two important things:
<wichert> joeyh: yada by itself is already sick
<joeyh> wichert: yes
<doogie> Diziet: stems from the fact that the .dsc format only allows 3 files.
<Diziet> Firstly, I want to see the source _that the .deb file's sendmail binary was built from_.
<doogie> Diziet: make -f debian/sys-build.mk source.make
<Diziet> Secondly, I want to do this _without having to trust the source package_. After all, I should be able to examine the source without having to trust it.
<doogie> Overfiend: http://master/~doogie/dbs_make
<doogie> Overfiend: ./dbs_make foo.dsc
<Diziet> w: Are you proposing that a single package might be extracted in different ways (ie, conditional extraction) ?
<wichert> Diziet: no
<doogie> ./dbs_make xfree86 4.0 xsrc4.0-1.tgz
<wichert> Diziet: I've decided conditional extraction is bad, since it allows you to get away with inconsistant patches
<Diziet> w: Perhaps the thing to do is this: if, when you add a change to a Debian package, you want to send it upstream, you should do this:
<doogie> note, dbs supports conditional extraction, I just haven't told anyone about it yet. :)
<Diziet> w: Right, I agree (re conditional). Good.
<Diziet> Use this utility of yours to apply everything except the debian diff.
<Diziet> Make your change, and diff it.
<doogie> dbs supports .gz, .z, .bz, .bz2, .tar, .zip, .jar
<Diziet> Now, send the diff to the upstream people in whatever is the usual way.
<doogie> Diziet: make -f debian/sys-build.mk make-diff
<Diziet> And then treat the new diff as an upstream patch; ie, just add it to the dsc (or use your utility)
<joeyh> hmm
<doogie> but it is NOT an upstream patch.
<wichert> Diziet: well, not until upstream merges it. until then it should be a debian patch..
<Diziet> doogie: Did you miss my second point ? That I want not to trust the source package ?
<doogie> if I muck around with the path settings that upstream has set, I doubt upstream will ever accept the patch.
<Diziet> w: Well, whether we call it `debian' or not is not quite relevant, is it ?
<wichert> Diziet: true
<doogie> Diziet: I don't understand what you mean by that.
<cesarb> doogie: so send a patched patch without path setting changes
<doogie> Diziet: upstream patches will have md5sums, and possibly other checksums.
<rcw> doogie: he wants to be able to look at source code without executing any of your scripts first
<Diziet> I mean, any long-running project has various semi-official patches floating about. We just treat it like one of those. The fact that we happened to produce the semi-official patch is irrelevant.
<doogie> rcw: not a fault of my scripts, but a limitation in the dpkg source format.
<joeyh> so effectively, there are two types of patches: permanant patches you have to make by hand, and the debian diff that catches everything else.
<Diziet> doogie: Suppose the debian/sys-build.mk contains this
<Diziet> source.make:
<Diziet> sudo rm -rf /
<Diziet> I want it not to execute it.
<rcw> doogie: you're talking to two people who can change the dpkg source format :P
<doogie> Diziet: suppose debian/rules contains the same thing.
<rcw> doogie: that's why they're asking you partly-rhetorical questions
<doogie> Diziet: suppose the upstream makefile contains the same thing.
<rcw> doogie: now think blue-sky, and answer the question
<Diziet> Currently, with dpkg-source (barring a known bug in tar) you can safely dpkg-source -x a .dsc supplied by the most evil person.
<joeyh> doogie: it's hard to do a full security autit and catch such things, before you have a source tree to audit.
<joeyh> the point is getting such a tree, securely.
<wichert> Diziet: tar is better in that respect now btw
<doogie> Diziet: ok, let me get this straight.
<BrritoBoy> Overfiend: try make -j :)
<netgod> Diziet: and you can read the source.make target before executing it to get the real code
<Diziet> (re tar) Oh, good.
<doogie> Diziet: you want me to trust dpkg-source -x, but not trust dbs?
<joeyh> doogie: extracting packages w/o dpkg-source -x is trivial and well-documented.
<rcw> doogie: the admin only has to look over dpkg-source once
<doogie> and if you don't trust dpkg-source -x, then there are known steps to extract a dpkg source pkg by hand.
<doogie> there are known steps to extract dbs pkgs.
<Diziet> netgod: Have you actually read these makefiles ? It would take at least an hour to do a proper audit.
<netgod> heh
<rcw> doogie: yes but they're extremely annoying steps
<doogie> Diziet: and you haven't read dbs files. they are extremely simple.
<Diziet> doogie: Supposing you get a mail from evil@earthlink.net with a dsc in it.
<doogie> I agree that a copy shouldn't be in each src pkg.
<joeyh> btw, anyone mind if I log this and post logs?
<doogie> joeyh: sure.
<Diziet> joeyh: No.
<netgod> Diziet: i would love if dpkg itself could manage multple patches, or failing that, debhelper
<doogie> er, no, I don't mind.
<rcw> joeyh: definately log it
<doogie> :)
<netgod> Diziet: iirc Klee did this once
<Diziet> What I'm saying is that if you dpkg-source -x it you are safe (barring bugs, obviously)
<doogie> netgod: NO!
<doogie> NOT PYTHON!
<rcw> that's actually great cuz I can make a phone call and read this later
<doogie> WE DO NOT NEED ANOTHER LANGUAGE USED BY DPKG! :|
<-- rcw has quit (brb)
<Diziet> Obviously it you run bits of makefile in it without reading them _very_ carefully you're in deep shit.
<dhd> doogie: says the dpkg-awk author
* bma hands doogie tr
<doogie> dhd: that is not used by dpkg programs, but by users.
<Diziet> netgod: Re multiple patches, Wichert and I have just been talking about that.
<Diziet> w: I think that perhaps you should post a proposed spec for your utility or whatever ?
<doogie> Diziet: with dbs, I was able to build kaffe statically against libungif4, and include both upstream sources in the .orig.tar.gz. I had to do this 'cuz potato had frozen, and this fixed an rc bug.
<Diziet> w: What happened to Klee's new source format, anyway ? Have you decided not to use it ? All I've ever heard about it have been rumours and vague descriptions, really.
<wichert> Diziet: I probably will, after I finish up actually releasing the spec for the new packageformat
<doogie> Diziet: it was python, and undocumented, and the author was inaccessible.
<wichert> Diziet: I have the tarball of it actually, have had it since august
<Culus_> new package format?
<netgod> Culus: packaging nirvana
<Diziet> wichert: Are you planning to release it ? Can you put it in project/experimental or something please ?
<doogie> Diziet: I am all for making something similiar to dbs part of dpkg-proper.
<doogie> Diziet: I made it a separate copy in each src pkg so that it wouldn't be a build time dependency.
<Diziet> Who cares whether dpkg_-source_ uses Python ?
<doogie> Diziet: it is another language.
<Diziet> doogie: So ?
<doogie> perl, shell, and c are enough.
<Diziet> doogie: Why ?
<doogie> Diziet: a language that would have to be available on the target platform.
<netgod> Diziet: so that complicates porting debian to a new architecture
<Diziet> doogie: Is python hard to port ?
<doogie> Diziet: what does that matter>?
<doogie> it is another unit that has to be ported by hand first.
<netgod> it took years before we could build dpkg without tetex, which is hard to port :)
<Diziet> True. But, for pretty much all the core packages it'll be very simple and you can just do it by hand, right ?
<xtifr> it's something else that has to be installed and debugged
<Diziet> After all we want the source format to be transparent anyway.
<xtifr> *and debugged*
<bma> making dpkg depend on python means we bloat base more
<doogie> bma: no, just dpkg-dev
<doogie> which isn't in base.
<bma> oh, dpkg-source
<-- wichert has quit (Ping timeout for wichert[wichert.cistron.nl])
<doogie> wich: can you give me a url to your proposed description?
<doogie> bah.
<Diziet> BTW, my free dialup disappears at midnight GMT so I disappear then too.
--> wichert (wichert@wichert.cistron.nl) has joined
<doogie> Diziet: what time is it there now?
<Overfiend> 20 mins till midnight
<doogie> ah, what I thought.
<doogie> Overfiend: you understanding that dbs file?
<Overfiend> doogie: haven't looked. sounds daunting
<wichert> Diziet: I think it's in ~wakkerma/klee.tar.gz on master or so
<doogie> wichert: can you give me a url to your proposed description?
<doogie> #!/bin/bash
<doogie> cat <<__DBS_EOF__|uudecode|gunzip|/bin/bash -s "super_dbs"
<doogie> begin-base64 644 -
* doogie loves that evilness.
<wichert> doogie: there is no url yet
<doogie> wichert: aw
<doogie> Diziet: I really wish you would look at the existing patch systems, if you haven't already.
<Diziet> wichert: Thanks.
<Diziet> doogie, you mean as used by sendmail ?
<doogie> Diziet: and x, and apache, and xawtv(which I maintain), and openldap, and pam
<doogie> all in all, over 25 pkgs are using the system.
<xtifr> I looked at dbs and decided not to use it
<doogie> Diziet: http://bugs.debian.org/52351
<Diziet> doogie: That's what I'm looking at now, and I don't like it for the reasons I've explained.
<netgod> hopefully any new system would have all of DBSs features, and more
<doogie> altho, please don't look at x's copy.
<doogie> it is old, antiquated, and pre-alpha
<netgod> xtifr: its overkill for any package whos source youre not actively patching yourself
<xtifr> netgod: yes, I know -- I did have a use for it, I just decided I disliked enough to not bother
<doogie> xtifr: what specific problems did you have with it?
<xtifr> anyway, it doesn't play very nice with cvs
<netgod> this is true
<doogie> known issue, with know known workaround.
<xtifr> doogie: purely conceptual
<doogie> s/know/no/
<doogie> manoj has tried to make it work with cvs-buildpackage
<doogie> but dbs and cvs-buildpackage are to solutions to the same goal, so I doubt they can work together.
<xtifr> yeah, I use cvs-buildpackage for all my packages
<Diziet> doogie: I'm afraid that telling me how many packages use it won't impress me. Lots of packages used debmake too.
<Diziet> doogie: cvs-buildpackage is excellent.
<doogie> Diziet: I'm also afraid that without very specific points as to what is wrong with dbs(it being 'hacked in' to the current system is known), I won't be able to improve it.
<Diziet> doogie: cvs-buildpackage produces source packages that look like every other kind of source package.
<xtifr> yeah, this isn't a popularity contest, and if it were, WinDOS would win! :)
<Diziet> Think of it this way: in the project it's not important how people do things internally - indeed, we must give people freedom.
<doogie> Diziet: um, but there are not the principle form of development for a pkg.
<Diziet> BUT it _is_ important that people all use the same standards for communicating _between_ each other.
<doogie> s/there are/that is/
<Diziet> Your packaging scheme violates that standard format. It makes it very difficult for other developers to work with your packages.
<doogie> Diziet: only those that don't know dbs.
<doogie> Diziet: some people have a problem with the .dsc/.diff.gz/.orig.tar.gz format.
<doogie> Diziet: "Why can't it be more like rpm?"
<Diziet> doogie: If you don't like the standard format the solution isn't to unilaterally ship something that noone else can use.
<doogie> Diziet: but other people can. dbs is just new.
<Diziet> The solution is to argue that the standard format needs to be improved, convince (enough) people, and implement it.
<doogie> Diziet: but wouldn't it be better to prove that something actually works, before going around changing things all of a sudden like?
<Diziet> `Why can't it be more like rpm' isn't a technical question, it's a political question. I treat it with contempt.
<doogie> Diziet: I have plans in my head as to how to make dpkg-source grok dbs files, automatically. Unfortunate, it is the same old problem.
<Diziet> doogie: No, because (a) I can't safely unpack a dbs package at all and (b) I don't know how to unpack a dbs package and (c) even if someone tells me it's still a pain.
<Diziet> doogie: Putting it in individual packages in the distribution isn't a test deployment.
<doogie> Diziet: it is a series of tars and zcat|patch cmds.
<doogie> Diziet: oh, I belive it is.
<Diziet> If you want to try out whether something is some good, write the code and put it in project/experimental.
<netgod> and when woody's dpkg can do what DBS does, it will quietly go away
<Diziet> No, not if it violates the standards that the project depends on.
<doogie> netgod: I have no problem with that.
<doogie> Diziet: what standards?>
<netgod> so improve dpkg, by all means
<Diziet> The dpkg source format is a core standard for Debian.
<doogie> Diziet: where does it say that .orig.tar.gz must have the same digital checksum as the file gotten from upstream?
<doogie> note: it isn't in policy.
<wichert> doogie: because right now we may end up having to modify it
<Diziet> Just because something isn't forbidden in policy doesn't mean that it's wrong.
<wichert> doogie: if that wasn't so we would make it policy
<Diziet> I mean, ... that it's not wrong.
<doogie> Diziet: if something is not in policy, who's to say whether it is wrong OR right?
<doogie> wichert: policy, or the src format?
<Diziet> The manual ?
<wichert> doogie: euh?
<doogie> <doogie> note: it isn't in policy.
<doogie> <wichert> doogie: because right now we may end up having to modify it
<doogie> <wichert> doogie: if that wasn't so we would make it policy
<Diziet> Do you agree that what you're doing is not the way dpkg-source is intended to be used ?
<netgod> this is like arguing that debmake is wrong -- its true, but it cant be killed without writing something vastly better first
<doogie> Diziet: no, I don't.
<netgod> so complaining about DBS is pointless, unless youre using those complaints to improve dpkg
<doogie> Diziet: I'm saying dpkg-source does not have the features I needed.
<gorgo> netgod: actually I think debhelper is vastly better...
<Diziet> debmake isn't quite the same. You see, if I download a debmakeified package I can still edit the source and rebuild without having to understand debmake.
<Diziet> True debmake is a bad idea, but it's not a violation of an interoperability standard.
<netgod> gorgo: as do i
<Diziet> doogie: If dpkg-source doesn't have the features you need you should add them.
<gorgo> netgod: and debmake still lives :/
<doogie> and because dpkg-source is a pain to work on(and patching it so that it functions with old and new formats is a difficult process(it was at the time dbs was invented)), I came up with something that didn't depend on dpkg-source.
<bma> stop saying deBMAke damn you
<netgod> lol
<Diziet> Are there any packages using dbs which don't have any significant upstream diffs ?
<netgod> no one wants to be associated with it :)
<joeyh> lol
<bma> Diziet: freeamp
<doogie> Diziet: let me run my script on master, and get the list of pkgs.
<doogie> but it might take more than 3 minutes to run.
<bma> but I'm moving away from DBS in woody.
<doogie> find /debian2/debian -name '*.diff.gz'|xargs -n 1000 zegrep -l '(sys|dbs)-build.mk'|sed 's,.*/,,;s,_.*,,'|sort -u
* doogie looks at bma
<bma> doogie: it is overkill for me.
<Diziet> Right, excellent. I shall file a bug report.
<doogie> see? dbs has too many features. :)
<doogie> file a bug?
<bma> Diziet: why?
<Diziet> Because it's clearly wrong.
<doogie> no it isn't.
<netgod> a bug against what?
<bma> it buidls from the source
<Diziet> What benefit does using dbs for freeamp have ?
<bma> Diziet: it did when I first packaged it
<doogie> a pkg using dbs is not a bug.
<bma> doogie: also, I am going to put the debian/ dir in freeamp's upstream source
<bma> dbs does not support it
<Diziet> It's a bug in our freeamp package that it uses dbs.
<netgod> fix dpkg, and make the new all-powerful package format policy, and then file bugs
<bma> Diziet: who the fuck do you think maintains freeamp? :P
<Diziet> freeamp doesn't need any features that aren't in dpkg-source.
<doogie> Diziet: you have given no reason why freeamp should not use dbs.
<doogie> Diziet: that is no reason to not use dpkg.
<netgod> until then, so long as debian/rules foo works, its hard to say the package is buggy
<bma> Diziet: I agree -- which is why I am moving it back to dpkg-source in woody.
<bma> I can't change it in potato.
<doogie> s/dpkg/dbs/
<Diziet> bma: So you won't object to my bug report then ?
<xtifr> doogie: it's a bug if the maintainer agrees its a bug, which he seems to :)
<doogie> xtifr: but only the maintainer can say that.
<Diziet> I mean, if you're going to fix it anyway I won't bother filing the bug.
<xtifr> doogie: no, though thought the maintainer can disagree and close the bug
<Diziet> Well, I don't want to argue about release policy in this rant as well :-).
<doogie> Diziet: but it isn't a bug that it doesn't used the advanced features that dbs provides.
<Diziet> If bma hadn't agreed I would have appealed to the Technical Committee.
<doogie> Diziet: is it a bug if I don't use dh_link, but run ln myself?
<Diziet> They would have had to vote with a 3:1 majority to overrule.
<Diziet> (And though I'm on it I wouldn't get a vote.)
<Diziet> (Because I was the complainant.)
<Diziet> doogie: It's a bug to use dbs without a good reason.
* doogie waits for his script to finish.
<dres> Diziet: because something used dbs?
<netgod> Diziet: this is opinion, not policy
<Diziet> Well, obviously it's opinion. Just because it isn't policy doesn't mean it's not true.
<Diziet> If dpkg dumps core that's a bug too, even though policy doesn't say things shouldn't dump core.
<bma> Diziet: don't waste your time filing the bug report. I will take care of it when 2.0.6 is released.
<bma> I used dbs for freeamp because I had a bunch of patches against it. The upstream author is very cooperative and merged them all upstream, plus, I have CVS write access now.
<xtifr> bma: i just use a local cvs repository :)
<bma> IMO, there is no reason why freeamp needs dbs anymore. or any other of my packages.
<bma> dbs is all fine and dandy, but it si more trouble than it is worth for me.
<doogie> Diziet: my script still isn't done, dinstall is slowing it down.
<doogie> ah, the script is done.
<doogie> 33 pkgs use dbs.
<doogie> Diziet: if you want this list, what is your email?
<Diziet> doogie: ian@davenant.greenend.org.uk is probably the right one.
<Overfiend> iwj@debian.org, of course :)
<Diziet> Thanks.
<Diziet> I have different addresses for different things.
<doogie> see?
<doogie> always better to ask.
<doogie> email off.
<wichert> Diziet: you have a weird mix of two hostnames and two accountnames.. :)
<Diziet> doogie: Thanks. Do you agree that it's a bug to use dbs if you have no upstream patches ?
<Overfiend> I don't
<doogie> Diziet: no.
<Overfiend> even if I have no upstream patches, I want dbs to keep track of the 93 patches I apply
<doogie> Diziet: for the same reason I don't believe it is a bug to use debhelper, when you could do everything by hand.
<Diziet> You disagree ? Why ?
<Diziet> of: Err, in what way are they not upstream ?
<doogie> Diziet: you meant to say no debian patches.
<Overfiend> Diziet: they don't originate upstream
<Diziet> If foo uses debhelper then I can still view foo/main.c without understanding debhelper.
<-- wichert has quit (zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
<Diziet> I can see foo/main.c without trusting the package.
<Diziet> And, I can edit foo/main.c and rebuild and reinstall without understanding debhelper.
<doogie> Diziet: no you can't.
<doogie> Diziet: it may have had a patch in diff.gz
<Diziet> doogie: You mean to say that if it uses debhelper and I say dpkg-source -x and then edit the source files something weird might happen ?
<gorgo> diziet: but can you rebuild without trusting the package ?
<doogie> Diziet: not at all.
<doogie> Diziet: you said you can look at foo/main.c, and trust that it has not been tampered with.
<doogie> Diziet: and that does NOT hold at all.
<Diziet> No, but in most packages the debian/rules is simple enough to audit and the .diff.gz doesn't tamper with the make system too much.
<doogie> Diziet: dpkg-source may have applied a patch from diff.gz
<doogie> Diziet: debian/rules(not using dbs) may patch it.
* dhd thinks that the dbs functionality should be in dpkg-source
<doogie> Diziet: and dbs is simple enough to audit.
<Diziet> doogie: I mean that I can safely view something that the source package claims is foo/main.c without compromising my account, no matter what the package has in it.
<dhd> diziet has a point, it's a bit annoying not to have the source immediately there after dpkg-source -x
<doogie> I have already given you the point that it should not be in each pkg.
<Diziet> Additionally, if the package isn't malicious what I will see is the foo/main.c which usr/bin/foo was built from so I can see how it works.
<doogie> Diziet: make -f debian/sys-build.mk source.build will unpack upstream sources, and apply upstream patches. source.make will apply debian patches.
<Diziet> I agree that functionality like this should be in dpkg-source.
<Diziet> doogie: Why are you telling me this rather than documenting it somewhere ?
<doogie> with the current system, there is no split between upstream patches and debian ones.
<dhd> he also has a point that at the moment dpkg-source is "trusted" (unlike SRPM :)
<doogie> Diziet: because I don't want dbs to be in wide spread use.
<doogie> the current users of dbs are a hand-tailored irc bunch.
<Culus_> dhd: Why is srpm not trusted? Those scripts it has?
<Diziet> Surely it should be documented in some readme file in the debian directory when I've done dpkg-source -x ?
<doogie> Diziet: did you read that bug report I gave you?
<dhd> culus: because an SRPM is just an RPM
<Diziet> After all, supposing I'm a developer who has no idea what dbs is I just get this totally weird source package and have no idea what to do without trawling through tons of obscure makefiles and shell glue.
<Diziet> doogie: Yes, I did.
<dhd> of course you'd also have to trust the process of building RPMs, which you can't
<Culus_> dhd: It is more than that isn't it?
<dhd> culus: nope
<doogie> Diziet: look at the build target in debian/rules, and it calls make -f debian/sys-build.mk source.make
<Culus_> dhd: I thought there was some kind of patching script they ran after unpacking?
<doogie> don't you have to be root to build an rpm?
<xtifr> otoh, you also cant trust dpkg --install (which is why we have to sign all packages)
<dhd> doogie: not if the spec file is written right, but people who write spec files don't realize this yet
<Diziet> doogie: The point is that understanding all that will take a fair amount of time, which could be saved by there being a readme !#
<dres> doogie: theoretically no. you can make a package that doesn't require that.
<dhd> there are still RPMs that don't use build roots, and thus install weird and random shit in your /usr
<doogie> Diziet: if this was all handled by dpkg-source, how much argument would you have with it?
<Diziet> None.
<Diziet> (Obviously to get something like this in dpkg-source we have to argue about it a bit to make sure we get it right.)
<dhd> the only thing I've noticed that's different about SRPMs is that they don't list the files they install (and thus don't show up in your rpm database), and they can be re-rooted to your local RPM build root (but RPMs in general are re-rootable so again I think this isn't unusual)
<Diziet> It could be that everything that dbs does can be done by Klee's mythical new source format.
<doogie> Diziet: but the split between the different parts that make up a source pkg that I have come up with seems to work.
<doogie> Diziet: but it is python, and another base dependency(not to be confused with a base pkg)
<Diziet> doogie: What kind of package has several Debian diffs ?
<bma> Diziet: don't know if you saw my response earlier, but don't waste your time filing a bug on freeamp, I'm taking care of it when they release 2.0.6
<Diziet> bma: I did see it thanks. Noted.
<bma> :)
<doogie> Diziet: glibc and gcc use a multi-patch system, but not dbs.
<bma> doogie: see, I need soemthing more like glibc.
<Diziet> doogie: base dependency ?? What's one of those ?
<bma> I like the ability to manage multiple patches
<bma> but I hate having to bury the tarball in special each time
<doogie> Diziet: something that the base programs need to run.
<doogie> bma: glibc/gcc do that as well.
<Diziet> None of the base programs run dpkg-source.
<doogie> bma: they just don't have it modular.
<bma> doogie: damn.
<doogie> Diziet: to build a deb, you need support programs.
<bma> time to roll my own little patch applier then :)
<woothead> Overfiend: They do what?
<doogie> bma: bah
<bma> that or just keep them seperate in the src directories
<Overfiend> rcw: yeah, I think so
<doogie> bma: I've looked at the glibc/gcc system, klee's format, and dbs.
<doogie> dbs has the most features, currently works, and the author is accessible.
<bma> never said it didn't work well. I just find it more of a burden than a convenience.
<xtifr> how does it handle conflicting patches?
<bma> it kills make
<Culus_> Probably the best thing to do is just make the source format more open an extendable
<Culus_> Everyone wants different things
<Diziet> The source format has to work `the same' for every package, even if there are extra features you can use.
<bma> doogie: ah
<Culus_> Diziet: The same being you type 'dpkg-source -x' and you get an upacked fully packed tree
<Diziet> Ie, you should be able to download, unpack, edit, build, etc. a package without having to understand a lot of package-specific stuff.
<Diziet> Right.
<Culus_> Diziet: The mechanics of how that happens do not need to be the same
<Diziet> I agree.
<Culus_> Diziet: So, if a trivial extention to dpkg-source was made to call an unpacking module then this could be developed outside of dpkg
<bma> now, esound would be a good thing ot use dbs on, because it has so many patches applied to it
<doogie> Culus_: hrm.
<Diziet> culus: Only if the unpacking module could be supplied out of band.
<Diziet> Unpacking a source package shouldn't require executing it.
<Culus_> Diziet: Yes, that is how I'd see it done
<doogie> I like extensible source format idea.
<doogie> another feature we have on rpm.
<Culus_> Diziet: The packages can build depend on this unpacker module package
<Diziet> But is there much benefit ? Remember that if we have many source formats we end up with all the usual problems associated with having lots of things:
<Diziet> There will be version skew between the unpacker and the format, etc.
<Culus_> Diziet: we already *have* multiple source formats, this cleans them all up
<Diziet> Perhaps it would be better just to update the current format to support the current crop of features people want.
<doogie> Diziet: the dbs system is quite stable.
* bma agrees with doogie on that one.
<Diziet> All of these other formats are all solving the same problems.
<Culus_> Diziet: You'd have to chat with espy about that
<Diziet> If we solve those problems well in dpkg-source then we can make life simpler for everyone.
<Culus_> he uses something different for glibc
<doogie> the fact that it is in use in 33 pkgs, while proving that it is rock solid, at least proves that it is stable. Those maintainers haven't been flooding me with new feature requests.
<doogie> Culus: I looked at that.
<doogie> dbs can do everything the glibc system does.
<doogie> but espy doesn't want to change.
<doogie> dbs is a new thing, and I can understand why people are afraid of it.
* rcw looks at doogie still trying to convince everyone that dbs is rock-solid and notes that he hasn't understood that that is irrelevant
<Diziet> doogie: The fact that 33 packages out of thousands are using it doesn't prove it's the right answer. The last time you bragged about numbers of packages I mentioned debmake. Did you forget ?
<doogie> rcw: <Diziet> There will be version skew between the unpacker and the format, etc., and to that I replied that dbs is stable.
<Diziet> If dbs were to become some kind of standard then we should look at it in more depth than I have yet.
<rcw> doogie: what everyone else is saying is that dbs is a hack, the features it implements should be more cleanly implemented, and that means *not in the source package itself*
<Diziet> doogie: Oh, I see. I was talking about these modular wotsits.
<doogie> Diziet: we have 2(??) systems in use for handling patches, and of the those, dbs has been used by more systems.
<doogie> rcw: have you not followed?
<Diziet> Maybe that's because you have better marketing.
<doogie> rcw: I have already said that multiple times, and not just during this session.
<doogie> Diziet: yes, I'll admit, I have pushed it rather hard.
<doogie> but that is because I want get it tested more, in more situations.
<rcw> doogie: something dpkg-source can be made to grok cleanly
<Diziet> doogie: So you admit you pushed it hard, and now you're bragging about how many people use it ? Feh.
<rcw> diziet: are you planning on basically throwing dbs's api into dpkg-source and using that to implement new .dsc commands?
<Diziet> No, I'm not.
<Diziet> Firstly, I'm not planning to do any work on dpkg at the moment.
<rcw> diziet: then what *was* doogie talking about? :)
<Diziet> Wichert is planning some things though.
<Diziet> I don't think that's one of them.
<Diziet> I think just throwing dbs into dpkg-source would be a mistake.
<Espy> a big one
<Diziet> I think that instead we should figure out what our requirements are and design something.
<Diziet> Then we can implement it.
<Diziet> Where we is probably Wichert :-).
<rcw> good :)
<Diziet> But it may be that Klee already did this. I haven't looked at his thing.
<Diziet> Right, I should go bed now.
<doogie> no.
<doogie> I will NOT use python.
<doogie> not as part of any dpkg base support.
<rcw> diziet: nice talking to you again
<Diziet> doogie: If Wichert decides to put Klee's stuff into dpkg-dev then you can take it up with him. If you don't like his answer convince the Tech Ctte.
<Diziet> But personally I think it wouldn't be a problem.
<-- Diziet has quit (Goodnight.)
--
see shy jo
Reply to: