Re: What warrants a non-maintainer release number?
On Tue, 6 Jan 1998, Christian Schwarz wrote: However, the `non-maintainer' part of this discussion is totally unimportant. What matters is the question `in which cases has the version number to be incremented and in which cases can it be left'? I think we all agree now that the version number has to be incremented whenever the binary package is changed on master (even in Incoming/). There are more complex aspects to this. I was talking to Christoph today and he mentioned that there were some cases with two different sources for packages. A simple example is his debs.fuller.edu where a number of experimental versions of packages are present. We also speculated that the KDE people might have custom releases of the KDE debs on the KDE CD and so on. We need to have some policy to prevent different .debs from having the same version number that covers this. For Deity at least is it VERY important that the version number of packages be exactly associated with the .deb file, there must never be two .debs with the same version that are not exactly the same. As soon as that happens it is no longer possible to tell which of the .debs are installed. Here is a possible example, for a time libc6 2.0.6 in main was was -0.1. What is someone had put an early release on debs.fuller also using -0.1, how is the person releasing into main to know that -0.1 is taken by the debs.fuller ppl? Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Jason Gunthorpe wrote: For Deity at least is it VERY important that the version number of packages be exactly associated with the .deb file, there must never be two .debs with the same version that are not exactly the same. As soon as that happens it is no longer possible to tell which of the .debs are installed. Indeed. Here is a possible example, for a time libc6 2.0.6 in main was was -0.1. What is someone had put an early release on debs.fuller also using -0.1, how is the person releasing into main to know that -0.1 is taken by the debs.fuller ppl? There has been some discussion about other people supplying .deb's on this list before. I think the general opinion was let the others take care of not conflicting with us. So, the people on debs.fuller should make sure that the version numbers they use will not be taken by 'official' .deb packages. I suggest using numbers like -0.0.1, depending on what kind of version numbers are used by the package. Remco -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 6 Jan, Remco Blaakmeer wrote: I think the general opinion was let the others take care of not conflicting with us. So, the people on debs.fuller should make sure that the version numbers they use will not be taken by 'official' .deb packages. This sounds nonsense. People at deb.somewhere will not care at all of our policies and package as they like (as KDE is doing); Debian's maintainer will get the complaints. You cannot expect that the _others_ will do in the right way. Ask Murphy. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Jason Gunthorpe wrote: On Tue, 6 Jan 1998, Christian Schwarz wrote: However, the `non-maintainer' part of this discussion is totally unimportant. What matters is the question `in which cases has the version number to be incremented and in which cases can it be left'? I think we all agree now that the version number has to be incremented whenever the binary package is changed on master (even in Incoming/). There are more complex aspects to this. I was talking to Christoph today and he mentioned that there were some cases with two different sources for packages. A simple example is his debs.fuller.edu where a number of experimental versions of packages are present. We also speculated that the KDE people might have custom releases of the KDE debs on the KDE CD and so on. We need to have some policy to prevent different .debs from having the same version number that covers this. Yes, this is another important issue. A possible solution to this has been presented in the recent KDE-virtual-package discussion on debian-policy: Each .deb should carry a new control field called Origin: or Distributor: or something like that. For example, all Debian packages would have Origin: SPI. This has to be combined with digital signatures on the packages so that noone else can put out an Origin: SPI package. With that, our package tools (dpkg, deity, etc.) could check for possible problems when packages from different sources are mixed. (Telling non-Debian people how which version numbers to use will definitely not work.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian has a logo![EMAIL PROTECTED], [EMAIL PROTECTED] Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA pages at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
[EMAIL PROTECTED] (Fabrizio Polacco) wrote on 06.01.98 in [EMAIL PROTECTED]: On 6 Jan, Remco Blaakmeer wrote: I think the general opinion was let the others take care of not conflicting with us. So, the people on debs.fuller should make sure that the version numbers they use will not be taken by 'official' .deb packages. This sounds nonsense. It's the only option we have. People at deb.somewhere will not care at all of our policies and package as they like (as KDE is doing); Debian's maintainer will get the complaints. You cannot expect that the _others_ will do in the right way. Ask Murphy. And no policy of ours can possibly change that, so we might as well just give up on that idea. We manage our version numbers, and as far as the project is concerned, non- project .debs are in no way a responsibility of the project. We might suggest ways to keep those numbers distinct to other people, but as we can't enforce that, we shouldn't even try. Simple example: someone grabs a source package and rebuilds it without any changes. He will now have a different .deb (and it _will_ be different - different time stamps, maybe he used a different gcc, different debmake version ...) with the exact same version number as the original. Just close bug reports referring to non-project .debs with not our package, not our problem. And maybe work on an official bug report tool with some chance of announcing who built that package (might need some support in dpkg-dev). MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Christian Schwarz [EMAIL PROTECTED] writes: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source ^^^ package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' I completely disagree with the last sentence. If I compile xfree for m68k and because of a broken ldd, it has hosed dependencies (this is not so fictional an example, it actually happened with ncurses), I should be able to recompile X with a different version number and *only upload binaries*. What would redoing and uploading the source get me or anyone else? o it takes 5 days to compile X on my machine, I don't even want to think how long it would take dpkg-source to work on a 42 Mb source tree. o it would spark off 100% pointless recompiles on other architectures. o it serves no purpose. The only source change is to the changelog, and that is included in the deb. And it doesn't help the rational of this policy (that is: source, or no source, dpkg/dselect will still recognise foo_1.2-1.0.1 to be newer than fo_1.2-1). -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
should be able to recompile X with a different version number and *only upload binaries*. What would redoing and uploading the source Yeah, my recent experience with the sparc port confirms this. At this stage, it seems that all of the non-x86 ports have system changes that aren't usefully reflected in dependencies so simple recompiles often fix real bugs. Of course, what I'd *really* like is a way to do an upload of diffs that are architecture specific; sure, we don't want that *in the end*, but while we're still getting there, lots of stuff is getting uploaded *without* matching sources, just to actually make it available... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 6 Jan, Kai Henningsen wrote: [EMAIL PROTECTED] (Fabrizio Polacco) wrote: On 6 Jan, Remco Blaakmeer wrote: So, the people on debs.fuller should make sure that the version numbers they use will not be taken by 'official' .deb packages. This sounds nonsense. It's the only option we have. The only option we have is to find a way to say if a package is official or not (and it cannot be its presence in the ftp site). Simple example: someone grabs a source package and rebuilds it without any changes. He will now have a different .deb (and it _will_ be different - different time stamps, maybe he used a different gcc, different debmake version ...) with the exact same version number as the original. Yes, and therefore, as Christian has just recalled, we need to add an origin field somewhere _inside_ the binary package. It cannot be included by the maintainer, because not all the packages that a maintainer build will become official, and also a maintainer can step out from the project (and still use his own pgp key). My suggestion was that dinstall will unpack the .deb , insert some signature in it (for example a md5sum list of the files in the control.tar.gz, pgp-signed with an official key), and repack it just before installation in the ftp hierarchy. (If the control.tar.gz contains the md5sums of the files installed by the package, then installing also this signed list into dpkg/info would add a way to check if a single file is the one distributed by us.) pgp-signing the Packages file could be another way to achieve this (the origin field), but will be too easily broken on rearranged distributions (e.g: your own mirror, or a custom CD), and the signature will be lost when updating the available list (that is to say: _before_ installation). Just close bug reports referring to non-project .debs with not our package, not our problem. The problem is knowing when a bug refers to a non-project package. When the user is sending us such bugs, probably he didn't notice or remember that the package wasn't build by us. Without a trusted origin field you will be prosecuted by the suspicion if the package is original or not. If the signature (that certifies that a package is debian-original), is installed in the dpkg database then we could have the bug command (or else) add automatically this information to the report. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Christian Schwarz [EMAIL PROTECTED] writes: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. Looks good to me. Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 5 Jan 1998, Michael Alan Dorman wrote: Christian Schwarz [EMAIL PROTECTED] writes: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. Looks good to me. I'm a bit confused by the context of these comments. What is being solved here? It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. All debian changes are reflected in the diff file produced by dpkg-buildpackage. Any changes to the debianized source (even a simple change in the dependencies) should create a new and unique version of the .deb .changes .dsc and .diff files, none of which requires either changing or uploading source files. What am I missing here? Waiting is, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. Here, source means Debian source, i.e. orig source + diff. In fact, you upload a new Debian source each time you upload a new diff. We are trying to clarify what happens when you just recompile a package. BTW: After the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package. I would add: You may want to use a point version number x.1 or x.5 and make it to disappear from the changelog as if it were never existed, as long as it is not released for stable. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLEmFyqK7IlOjMLFAQGk1QQAkunssgl4fkpPCLl6uv5uoRFYsmsdK7PZ 48i9g9K71+jiyYkxbjPh/uwak4CBjjbObfZcWryBalQ85omrOvktPcpdssxUdMnu 4V0HoiAmFxSaYczaZZauCzgR8mGDgFtdh4EuUELKyr8xKRCfEDWpAk0DolYEU98k 7WdpgUD8XUQ= =Qxo2 -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: [snip] BTW: After the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package. I would add: You may want to use a point version number x.1 or x.5 and make it to disappear from the changelog as if it were never existed, as long as it is not released for stable. I think removing entries from the changelog is usually a bad thing, even for dot releases. Sometimes, the changelog is very useful to get some background info about the version one has installed. Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. Here, source means Debian source, i.e. orig source + diff. In fact, you upload a new Debian source each time you upload a new diff. We are trying to clarify what happens when you just recompile a package. Then we are still discussing non-maintainer uploads/version numbering. In that case I find the paragraph to be ambiguous, confusing, and not to the point. If there is a reason to upload a new .deb package then that alone is sufficient to require an incremented version number. Every new release of a package should come with a new version. Only if an md5 sum of the new package is identical to that of the old would the version remain the same. In that instance there is no reason to upload the new file. Luck, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Christian Schwarz wrote: On Mon, 5 Jan 1998, Santiago Vila wrote: [snip] BTW: After the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package. I would add: You may want to use a point version number x.1 or x.5 and make it to disappear from the changelog as if it were never existed, as long as it is not released for stable. I think removing entries from the changelog is usually a bad thing, even for dot releases. Sometimes, the changelog is very useful to get some background info about the version one has installed. We want to release hamm as soon as possible. Therefore everybody should use the latest release of each package. If you release x, recompile it and call it x.1, and later release x+1, I don't see why x.1 should be kept in the changelog, being it just a recompile. I still think that changelog is *mainly* the history of *source* changes. If we increment it just for a recompile is because dpkg needs it to see that a package is newer. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLE7uSqK7IlOjMLFAQEsrQP7Bp1Q+ih4hUNY687sAIxBYv5ye7DBx777 nnKkccy77eyj7Riwt82y7xThp2wP0UK1iHyilaUjgIH5woDNePpPaSjAULAxsINm eTAfASKNiTRlXIk5nE2YWDQC2xFX7+DA4pvkqFHlv8aiZG56BBzDb5BEAJxMVeo1 aiKesL9rQtE= =F9jz -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: On Mon, 5 Jan 1998, Santiago Vila wrote: On Mon, 5 Jan 1998, Dale Scheetz wrote: It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. Here, source means Debian source, i.e. orig source + diff. In fact, you upload a new Debian source each time you upload a new diff. We are trying to clarify what happens when you just recompile a package. Then we are still discussing non-maintainer uploads/version numbering. In that case I find the paragraph to be ambiguous, confusing, and not to the point. Maybe, but the official maintainer should also be able to do a recompile of his own package :-) Why do you think we are still discussing non-maintainer uploads? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLE89yqK7IlOjMLFAQFDUgP/aQX5mNcI06vbVewU9PSY07/yRuKN3sMT 0BFawG1KmHCLYR0pq8aFn8pXSo6+8H+8uNQDhs4hDQwFJJFhotwxRIroTPp04ROd 8oIHz2NzrebL0RdrA0XSZQcnHxB5BA7MtLTIlfpJ2/5XrmIj9/DTXMuVMohe55I1 OJD8ErmfGV4= =QRsk -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: Then we are still discussing non-maintainer uploads/version numbering. In that case I find the paragraph to be ambiguous, confusing, and not to the point. Maybe, but the official maintainer should also be able to do a recompile of his own package :-) Why do you think we are still discussing non-maintainer uploads? I don't know ;-) that's why I got into the discussion. I had thought that we decided to add point numbers to the debian release increment, so a non-maintainer upload of ae_962-17 would be numbered ae-962-17.1 allowing the maintainer to do a -18 upload without confusion. This is, however, a different issue from, when do I change the version number, isn't it? Any binary package upload that differs by a single bit from the previous version should be provided with a new version number. At the very least, a change in the packages used to build said new package should result in new information in the change log, asside from the resultant changes to the binary. These are each sufficient to create a new version. What have I missed? Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
[EMAIL PROTECTED] (Dale Scheetz) wrote on 05.01.98 in [EMAIL PROTECTED]: If there is a reason to upload a new .deb package then that alone is sufficient to require an incremented version number. Every new release of a package should come with a new version. Only if an md5 sum of the new package is identical to that of the old would the version remain the same. In that instance there is no reason to upload the new file. Very much me too here. Version numbers are not for the convenience of maintainers. Version numbers are for the convenience of users. As such, they need to change whenever the .deb changes. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 5 Jan, Christian Schwarz wrote: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. What about: The version number of a previously uploaded package must be incremented on every change in one of the md5sums listed in the .changes file, even in absence of other modifications to the package's contents. or: After a package has been uploaded (even if not installed), you must always increment the debian version number before uploading it again if any of the md5sums in the .changes file has changed. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E pgp1HNuAtTOhF.pgp Description: PGP signature
Re: What warrants a non-maintainer release number?
Why do you think we are still discussing non-maintainer uploads? I don't know ;-) that's why I got into the discussion. The discussion started when someone (I forgot who :) did a non-maintainer upload for another architecture _twice_, the second time with different depedencies (resulted from simply recompiling) but with the same version number. However, the `non-maintainer' part of this discussion is totally unimportant. What matters is the question `in which cases has the version number to be incremented and in which cases can it be left'? I think we all agree now that the version number has to be incremented whenever the binary package is changed on master (even in Incoming/). (The only situation where one can upload a binary package twice without changing the version number would be when the first upload wasn't successful--i.e., the fules got truncated.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 3 Jan 1998, Michael Alan Dorman wrote: Christian Schwarz [EMAIL PROTECTED] writes: By changing the dependencies you changed the source package before, or? Technically, no. The dependencies are build by dpkg-shlibdeps, so for all intents and purposes, the *only* difference between the old package and the new was the things totally external to the package and sources that were installed at the time. Oh, I see. But if I recall correctly, the old package was already uploaded to master (but stuck in incoming). And then the new package (with same source package--but different binary package) has been uploaded using the same version. This is bad since dselect/dpkg will not know that something changed. Anyways, we are not talking about that situation. This is past now. But we should talk about some guidelines that we can include in our documentation (this should go into the Developer's Reference I think) to avoid these troubles next time. How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 27 Dec 1997, Michael Alan Dorman wrote: Christian Schwarz [EMAIL PROTECTED] writes: On 17 Dec 1997, James Troup wrote: [snip] If the binary changes, the version number should change. Completely agreed. Everything else will only result in a big mess. I'll check our how I can make policy more clearly on this point and include something in the next policy weekly posting. Of course, are you talking about the binary program, or the binary .deb? The binary program in question *did not change*, because its compilation and linkage environment's (effectively) did not. The *only* think that changed here was the dependency in the .deb. Just a twist to consider. By changing the dependencies you changed the source package before, or? With that, you'll have to use a new version number anyways. Anyway, I guess I didn't mean to start a big debate---I was pretty much convinced after Sven first mailed me that I probably ought to have bumped the version number. I just thought the policy should also be more explicit. Agreed. (That's why we should continue the discussion until we have a consensus.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Christian Schwarz [EMAIL PROTECTED] writes: By changing the dependencies you changed the source package before, or? Technically, no. The dependencies are build by dpkg-shlibdeps, so for all intents and purposes, the *only* difference between the old package and the new was the things totally external to the package and sources that were installed at the time. Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Christian Schwarz [EMAIL PROTECTED] writes: On 17 Dec 1997, James Troup wrote: [snip] If the binary changes, the version number should change. Completely agreed. Everything else will only result in a big mess. I'll check our how I can make policy more clearly on this point and include something in the next policy weekly posting. Of course, are you talking about the binary program, or the binary .deb? The binary program in question *did not change*, because its compilation and linkage environment's (effectively) did not. The *only* think that changed here was the dependency in the .deb. Just a twist to consider. Anyway, I guess I didn't mean to start a big debate---I was pretty much convinced after Sven first mailed me that I probably ought to have bumped the version number. I just thought the policy should also be more explicit. Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Santiago Vila [EMAIL PROTECTED] writes: On 17 Dec 1997, James Troup wrote: Michael Alan Dorman [EMAIL PROTECTED] writes: This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. I hope Guy will reject that. If the binary changes, the version number should change. This is that way because our package system does not allow several binary packages for the same source package. True. But it should. Maybe. Or not. How often do we need it and how much of a mess would this add? IMHO the reason why Michael Alan Dorman hesitated to increase the version number is that he considered the alpha-specific recompile a change that should not affect any other architecture. Please note that such considerations didn't occur with the big libc6 recompile for i386. In the end such an architecture-specific recompile implemented as non-maintainer release will cause recompiles on all architectures. This is only a problem when this happens too often. IMHO the current state doesn't have too much impact, because: - either the recompile is done manually. Then the person doing this can choose to not build a binary architecture for an architecture where this isn't necessary. - or the recompile is done automatically, then it doesn't consume human time. hello_1.3-0 (compilation 0) is older than hello_1.3-0 (compilation 1) and dpkg will see the need to upgrade. This might make a good idea, but I think it is too much change for too few cases. Sven -- Sven Rudolph [EMAIL PROTECTED] http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
James Troup [EMAIL PROTECTED] writes: If the binary changes, the version number should change. Things break if you don't increase the version number (e.g. automatic upgrade and bug reporting) and you don't have to a source release to do a non-maintainer release, just add a new entry to the changelog before you recompile. I agree. Remember that many people won't even *notice* this new version of the package because dselect won't tell them about it. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
[EMAIL PROTECTED] (Santiago Vila) wrote on 17.12.97 in [EMAIL PROTECTED]: On 17 Dec 1997, James Troup wrote: Michael Alan Dorman [EMAIL PROTECTED] writes: This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. I hope Guy will reject that. If the binary changes, the version number should change. This is that way because our package system does not allow several binary packages for the same source package. But it should. Huh?! If the binary changes, the version number should change. It doesn't matter _why_ the binary changed. Several binary packages for the same source? What on earth has that to do with it?! Besides, how is it that the system doesn't allow it? I thought we had several of those. Stuff like, say, X. Things break if you don't increase the version number (e.g. automatic upgrade and bug reporting) and you don't have to a source release to do a non-maintainer release, just add a new entry to the changelog before you recompile. Again this is a limitation of our current source|binary packaging scheme. Does not mean it has to be that way. Sounds to me like exactly the way it _should_ be. What advantage do you see in *not* changing the version number? Changing the *source* version number would be a gratuitous change. We're talking of the Debian release version, here. I don't understand why that bugs you; it seems the right thing to me. It would be really nice to have something like epochs for binary packages coming from the same source. i.e. hello_1.3-0 (compilation 0) is older than hello_1.3-0 (compilation 1) and dpkg will see the need to upgrade. That would just needlessly confuse users. Gratuituous confusion is something we can do without, I think. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 17 Dec 1997, Michael Alan Dorman wrote: This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. Policy people? Any suggestions? Found out today, that the source is missing some files, among them, the configure scripts... It also have some core files... --- Turbo_ /// If there are no Amigas in heaven, send me to HELL! ^\\\/ Unix _IS_ user friendly - it's just selective about who its friends are ! Turbo Fredriksson Tel: +46-704-697645 S-415 10 Göteborg[EMAIL PROTECTED] SWEDEN www5.tripnet.se/~turbo My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html' Key fingerprint = B7 92 93 0E 06 94 D6 22 98 1F 0B 5B FE 33 A1 0B --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On 17 Dec 1997, James Troup wrote: you don't have to [do] a source release to do a non-maintainer release, just add a new entry to the changelog before you recompile. Well, if this is so, this would be the best solution. Just call it dpkg-1.4.0.19.0 and do not upload a new diff. This way, there will be no traces of 1.4.0.19.0 in 1.4.0.20's changelog. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNJkLJyqK7IlOjMLFAQGwJwP8CZTQE+WZHBnXAlBoFhFeUZFpDgdX8XIi VzsoPcmskG98eISx5iEMi1AnEVyBWkXPKJCzyn8H7Lb0YsYsxY4JtG/ny/oHZoco PG+ectPE7uXk8Z9ZJUdUEYnnMejZyrLZuS7mb4ZDj7JXrTULlO4zCPSDxPwnwPqu Vlzr7H4fUqY= =WPFs -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
What warrants a non-maintainer release number?
This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. Policy people? Any suggestions? Mike. ---BeginMessage--- Michael Alan Dorman [EMAIL PROTECTED] writes: Sven Rudolph [EMAIL PROTECTED] writes: Michael Alan Dorman [EMAIL PROTECTED] writes: This is simply a recompile to pick up current libraries, libg++272, ncurses3.4, etc. If you could please shove it in, despite the version number match, I'd appreciate it. I've cc:'d debian-alpha so they'll know it's there as well. IMHO you should make such a recompile a regular non-maintainer release. I thought about it, but it's literally 0 source changes, simply a recompile. non-maintainer-release suggests source changes to me---as I have just done with gpm. But it is the official mechanism to tell people that something changed. Whenever someone reports a bug and includes the complete version number you have to ask whether he took the old or the new one. We might want to turn ithis into a policy topic. Sven -- Sven Rudolph [EMAIL PROTECTED] http://www.sax.de/~sr1/ ---End Message---
Re: What warrants a non-maintainer release number?
Michael Alan Dorman [EMAIL PROTECTED] writes: This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. I think if you browse the changlogs of various package, you'll see a number with non-maintainer releases with entries like: * recompiled for libc6. So I'd say the practice, at least, is that code changes are not a necessary criteria. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Michael Alan Dorman [EMAIL PROTECTED] writes: This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. I hope Guy will reject that. If the binary changes, the version number should change. Things break if you don't increase the version number (e.g. automatic upgrade and bug reporting) and you don't have to a source release to do a non-maintainer release, just add a new entry to the changelog before you recompile. What advantage do you see in *not* changing the version number? -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On 17 Dec 1997, James Troup wrote: Michael Alan Dorman [EMAIL PROTECTED] writes: This is part of an email exchange Sven and I had. Simply put, I put in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a recompile to pick up new libg++, ncurses, etc. Sven suggested that this warranted a non-maintainer-release number, whereas I had gotten the idea that non-maintainer-releases suggested code changes. I hope Guy will reject that. If the binary changes, the version number should change. This is that way because our package system does not allow several binary packages for the same source package. But it should. Things break if you don't increase the version number (e.g. automatic upgrade and bug reporting) and you don't have to a source release to do a non-maintainer release, just add a new entry to the changelog before you recompile. Again this is a limitation of our current source|binary packaging scheme. Does not mean it has to be that way. What advantage do you see in *not* changing the version number? Changing the *source* version number would be a gratuitous change. Packages coming from the same source should be allowed to share that common source, without changing it at all. That is the meaning of source. But we currently include the changelog in the source and make it to refer both to binary and source changes. This is not very elegant. It would be really nice to have something like epochs for binary packages coming from the same source. i.e. hello_1.3-0 (compilation 0) is older than hello_1.3-0 (compilation 1) and dpkg will see the need to upgrade. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNJghtCqK7IlOjMLFAQEdYwQAqG2tfw5hgxDS8CFPnsriZNVTEKe3DokP D8hZAfM2opG+hrPxkBajgsHh4rh/fqsPptEQEsZHIi71HqAN3qjhs7kTvs+PxCQf 3AVrIfToF96ROY29RQW5IS8uj88Aj9eCpElI7e5VoFfoFGXI3zcWf/lRkldbFJHo QZqGK+wHjuw= =9qvc -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Santiago Vila [EMAIL PROTECTED] writes: This is that way because our package system does not allow several binary packages for the same source package. But it should. [...] Again this is a limitation of our current source|binary packaging scheme. Does not mean it has to be that way. [...] I was talking about reality and not about what might/should/could be. If you want to talk about whatever, fine, I don't care, but please don't confuse this issue. The fact of the matter is *currently*, uploading a new version of a .deb with the same version number is wrong, IMO. What you think our packaging system should be doing at some unspecified time in the future has nothing to do with it. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 17 Dec 1997, James Troup wrote: [snip] If the binary changes, the version number should change. Completely agreed. Everything else will only result in a big mess. I'll check our how I can make policy more clearly on this point and include something in the next policy weekly posting. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
