[i CC'ed debian-devel mailing list in order to being refuted on wrong positions i take on debian behalf] On Wed, Jun 06, 2001 at 02:14:06AM +0200, Trick wrote: > > http://www.debian.org/doc/debian-policy/ch-versions.html > > According to that page the debian revision number is only needed if the > software doesn't support debian out-of-the-box, or if that information is > incorrect. GNUpdate supports debian natively, so the only reasons we would > need one is if the debian policy changed. If that should happen nothing keeps > you from making a diff to the original tarball and append the debian revision > number.. > if package is native, it is native, i cannot append any debian revison number. if i need to do 300 uploads (and the source package is the native one, the one without diffs) to undestand a feature of debian, you all need to do 300 new releases. if the package is not native, i make all the 300 uploads (with 300 diffs and only one original tarball) with the same release you made once. is this clear?!? (well, if i make 300 uploads because i don't read policy my karma drops drammatically, if i have any...) > If something the software depends on changes, that shouldn't be a problem if > the changes are backwards-compatible. If they're not backwards-compatible, > the software should change as well, and so you don't need a debian-revision > for that either. > yes, i only need to re-upload all the mess, even if it was a mistake of me relative to debian files *i* maintain. this is not clever. > > producing diffs is the way new modifications are applyed to packages > > already in archive. why the hell i need to upload a new complete > > modified upstream source tree when i only modified a little part > > regarding debian details?!? better upload only modification! > > Right. Nothing keeps you from doing that. If you change something in the > debian dir that should be applied to a current package, just diff it to the > previous version and release the diff. What's the problem ? > i cannot do an upstream release, so i cannot make a diff with an older one. i depend from you to do *my* job for debian. i don't like this. i thinks nobody in debian likes this. > > upstream code is less likely modified than the debian code needed for > > it to being packaged. > > > > this is reason why debian sources are made by original source tarball > > and a diff file. > > When the software doesn't support debian natively, yes, but GNUpdate does.. > are you really ready to make a new release whenever i need to make a new release for debian?!? are you sure about what you are saying? supporting debian the way you meant means this also. > > be sure, none of them gets its debian package built directly from the > > tarball they release. all debian developers that receive a tarball with > > debian directory generete a diff file, maybe empty for the first upload > > of a new upstream version. making debian native packages, which have not > > a diff, from not debian software is a serious policy violation. software > > that violates policy DO NOT REACH the stable distribution. > > > > for details, see > > http://www.debian.org/doc/developers-reference/ch-archive.en.html#s5.5 > > This means that we need an empty .diff.gz-file even if there is no changes, > just because the software is not debian-specific (although it does support > debian natively) ? That seems a bit weird to me, but if that's the policy, > nothing keeps you from creating that empty file.. > i was wrong, policy do not say anything about this topic (native vs. plain). anyway other rationales let doing a clever choices. > > oh yes... but for sure they don't build the debian package they upload > > to debian servers directly from your cvs or your tarball. if they do > > and don not generate a diff file they are *wrong* and their packages > > cannot go in stable. > > Ok, you lost me. What are you talking about ? > i was talking about making native packages instead of plain ones. i was convinced that policy enforced the use of native packages only for software specifically developed for debian. with this assumption, making a native package for gnupdate stuff would have been a policy violation. policy violations freze a package until they are removed. anyway i was wrong, we _could_ make debian native packages. > > if i'm packaging libgnurdf 0.2.0, its tarball is somewhere in this little > > world. and in debian/control i say where i downloaded it. > > Where you *downloaded* it ? If the software supports debian natively ? > software is downloaded from whoever happens to develope it, in this case from gnupdate.org. debian software can be downloaded *only* from debian servers and mirrors. software that runs on debian might not be in debian distribution. example, ximiam (ex helix) is not debian software, even if it supports and installs on debian systems and provides (i suppose) good debian packages. > CVS is supposed to be unstable and outdated here and there. It's the > developers' working copy. Making debian packages from that is incredibly > stupid. However, when a new official, stable release occurs, everything is > updated and should work out-of-the-box, which of course means that the debian > dir is also updated, again because GNUpdate supports debian natively. > do you want to support debian or you want gnupdate to be also part of debian distribution? if it has to be part of debian distribution, it will be distributed for sure by debian mirrors and cdroms et al. if you also want to distirbute it, it will not be the official debian version. this is not dependent on the fact the the person maintaining the debian package of you software is the same that maintain the debian/ dir in your CVS. > In other words, any stable version of any software should work out of the > box. If it doesn't, that's a bug. > well, which is the target? unstable distribution, the stable one or what? debian software, before reach light with stable distribution, gets tested for long time together all the other software is going to be published in stable. in order to make gnupdate stuff reach stable debian distribution it has to be packaged on unstable machineis (new libraries, new dependencies...) which happens to have the most recent (and buggest) software available on internet. a new release of a debian package usually do not run on a currently stable system. do you consider bugs also these ones? ah, before you ask me... new upstream version of software cannot be uploaded on stable distribution. new packages are uploaded on stable only if they fix security and serious policy violation bugs. bugs fixes, althought might have been already included in subsequent upstream releases of the software, *must* be backported to the upstream version included in stable distribution. do you want to grant this service too?!? this is implied when you say that you are supporting debian. > > i find clever and somewhat required (it is the right thing to do) to have > > debian/ in your cvs, i agree with you. anyway i never handled it and i'm > > facing some problems i never faced before, many of us (debian packagers) > > already solved them. i still have not. > > > > since i cannot handle this right now (this is at least the second time > > i say that), please do not get angry if debian/ in cvs is not so update. > > As long as it's updated at new official, stable releases, that shouldn't be a > problem.. > no, this should not be a problem, really. > > whenever you publish this damned tarball i'll download it, i'll look at > > it, will try to compile and i'll make the required changes to make it a > > good debian package. then i'll upload to debian archives and i'll update > > debian/ in your cvs. what's wrong with this?!? debian packages are made > > and uploaded, debian/ cvs is updated. the only flaw is that your tarball > > probably do not compile right out of the box. but think at it a little, > > who the hell will compile it from your sources when he has it in debian > > archives?!? i say you, nobody. > > Any released tarballs should work out of the box. Period. > on which debian systems?!? unstable, testing, stable? you cannot reach testing and stable ssytem directly, you have to pass by unsatble and testing... > > if i was offensive somewhere, please forget it, it was not intentional. i renew this statement :) > You might benefit from getting some rest.. > i got it :) > Gerry > Domenico -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Attachment:
pgpABlzQdCwqt.pgp
Description: PGP signature