Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Fri, Apr 26, 2019 at 02:27:58PM +, Holger Levsen wrote: > > > > > > I see no point whatsoever in 3.0 (native). > > > > What's the point/advantage of native packages? > > > No need to make a separate orig tarball. > > the irony here is that native packages also require an upstream tarball, Sure, but you can just tar everything you have. -- WBR, wRAR signature.asc Description: PGP signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Sat, Apr 13, 2019 at 03:13:17PM +0200, Alf Gaida wrote: > > > > > I see no point whatsoever in 3.0 (native). > > > What's the point/advantage of native packages? > > No need to make a separate orig tarball. the irony here is that native packages also require an upstream tarball, it's just that dpkg-buildpackage will create that automatically. > Can't agree more, there are places where 3.0 (quilt|git|anything else) don't > make any sense, think about meta packages with no upstream tarball and such > things. ok, so this is one use case, empty packages. I'm glad I learned something in this thread. Thanks. :) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
> "Marco" == Marco d'Itri writes: Marco> On Apr 15, Sam Hartman wrote: >> However if my sources are in git, git is the definitive format >> for thinking about things, and the dsc I'm producing is only for >> the convenience of the archive, I don't want to deal with an >> upstream tarball. Marco> Generating an upstream tarball in this case is still useful Marco> because this way we do not need to upload and store forever Marco> the full source archive every time that something changes Marco> only in the packaging. How important is this in practice, and at what size package does this become a real issue. It seems that it depends on: * Source being some significant fraction of the binary size * The package being large enough this matters * The package getting differences in packaging that do not involve changes outside of packages often enough. Remember that for the packages we're talking about here, any change to things outside of debian would count as a new upstream I agree that 20 years ago when I started in Debian this was a real issue for a lot of packages. My strong suspicion now is that we would be better off making things easier for our developers than focusing on what I think is a relatively unimportant disk space savings. There are doubtless a fewt packages that are really large and that do tend to get package-only changes often where the upstream split makes sense. However, I think for a lot of packages we're better off making it easier for developers and trying to get pushing a package update into something where it can fit into a smaller time slice that gets serviced more often than something that takes a large chunk of time. --Sam
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
Hi, On 15.04.19 21:23, Marco d'Itri wrote: > Generating an upstream tarball in this case is still useful because this > way we do not need to upload and store forever the full source archive > every time that something changes only in the packaging. That, and upstream tarballs generated with "git archive" have a magic comment tag that says which revision was used to build them, so we don't even lose information. $ git archive --format=tar HEAD | git get-tar-commit-id 973188bd3b4628646c53ca9ab9bf71cc95eadd43 Simon signature.asc Description: OpenPGP digital signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Apr 15, Sam Hartman wrote: > However if my sources are in git, git is the definitive format for > thinking about things, and the dsc I'm producing is only for the > convenience of the archive, I don't want to deal with an upstream > tarball. Generating an upstream tarball in this case is still useful because this way we do not need to upload and store forever the full source archive every time that something changes only in the packaging. -- ciao, Marco signature.asc Description: PGP signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
>>>>> "Holger" == Holger Levsen writes: Holger> On Sat, Apr 13, 2019 at 01:48:01PM +0100, Simon McVittie wrote: >> On Sat, 13 Apr 2019 at 10:04:10 +, Holger Levsen wrote: >> > I see no point whatsoever in 3.0 (native). The main advantage >> of 3.0 (native) is that it makes it explicit that the package is >> deliberately native [...] Holger> ok, sorry, I ment to say: I see no point whatsoever in Holger> native packages. AFAICS there are no advantages, just Holger> downsides. I work on a lot of packages that don't really produce upstream tarballs. It's painful and makes the workflow less fun to have to go deal with upstream tarballs myself and I don't think it adds anything to the workflow. Upstream tarballs are perhaps nice if upstream actually produces them (although I think even that is a discussion we may want to have long-term as we move everything to git). However if my sources are in git, git is the definitive format for thinking about things, and the dsc I'm producing is only for the convenience of the archive, I don't want to deal with an upstream tarball. This is even more true if I happen to be using dgit. --Sam
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On 13.04.19 15:07, Andrey Rahmatullin wrote: On Sat, Apr 13, 2019 at 12:59:19PM +, Holger Levsen wrote: I see no point whatsoever in 3.0 (native). What's the point/advantage of native packages? No need to make a separate orig tarball. Can't agree more, there are places where 3.0 (quilt|git|anything esls) don't make any sense, think about meta packages with no upstream tarball and such things. And i wouldn't consider 1.0 bad or smelly, i use it on a regular base for git based builds in my experimental snapshots, it's simply the best format to do so (just put the new sources in and be done with) Cheers Alf
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Sat, Apr 13, 2019 at 12:59:19PM +, Holger Levsen wrote: > > > I see no point whatsoever in 3.0 (native). > > The main advantage of 3.0 (native) is that it makes it explicit that > > the package is deliberately native [...] > > ok, sorry, I ment to say: I see no point whatsoever in native packages. > AFAICS there are no advantages, just downsides. > > What's the point/advantage of native packages? No need to make a separate orig tarball. -- WBR, wRAR signature.asc Description: PGP signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Sat, Apr 13, 2019 at 01:48:01PM +0100, Simon McVittie wrote: > On Sat, 13 Apr 2019 at 10:04:10 +, Holger Levsen wrote: > > I see no point whatsoever in 3.0 (native). > The main advantage of 3.0 (native) is that it makes it explicit that > the package is deliberately native [...] ok, sorry, I ment to say: I see no point whatsoever in native packages. AFAICS there are no advantages, just downsides. What's the point/advantage of native packages? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Sat, 13 Apr 2019 at 10:04:10 +, Holger Levsen wrote: > I see no point whatsoever in 3.0 (native). The main advantage of 3.0 (native) is that it makes it explicit that the package is deliberately native, whereas a 1.0 native package is indistinguishable from a package that was intended to be 1.0 non-native but ended up native because the maintainer forgot to have the orig.tar.gz in the right place when building it. (The presence or absence of a -revision in the version number should in theory be well-correlated with non-native or native packaging, but this doesn't always hold - for example python3-defaults is a native package with a non-native-style version number. Perhaps Policy should require packages like python3-defaults to use a native-style version number like 3.7.3+1 instead of 3.7.3-1?) dpkg also compresses 3.0 (native) packages with xz by default. smcv
Bug#865989: ITP: ruby-native-package-installer -- Ruby library to help install native packages on "gem install"
Package: wnpp Severity: wishlist Owner: "HIGUCHI Daisuke (VDR dai)" <d...@debian.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-native-package-installer Version : 1.0.4 Upstream Author : Kouhei Sutou <k...@clear-code.com> * URL : https://github.com/ruby-gnome2/native-package-installer * License : LGPL-3+ Programming Lang: Ruby Description : Ruby library to help install native packages on "gem install" Users need to install native packages to install an extension library that depends on native packages. It bores users because users need to install native packages and an extension library separately. native-package-installer helps to install native packages on "gem install". Users can install both native packages and an extension library by one action, "gem install". - - This is needed for new upstream release of Ruby-GNOME2: https://tracker.debian.org/pkg/ruby-gnome2 - - This is maintaind by me and Debian Ruby Extras Maintainers. - -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E -BEGIN PGP SIGNATURE- iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAllQ4zwPHGRhaUBkZWJp YW4ub3JnAAoJEHg5YZ3UOWaON/MP/jxApr1LfY73QH7AbwC+XlEdKctiS33WqvB8 VziNrWNejAgEDPRGg4+IeAkBXejLxZ1z2WRjlVlwXfYtpMrM5HAxyRQZckHH1wac 6GnPnavJC7Rs5Ym7Ie0V5PWXlarRwo1FLpFzlrSUz2LzO1tsUmWpPrpFMEiJM38Z P4GMm6sUTr88ddJM1i0+LB8bL6rBqdXXeoPScjeDVe9dePjOhFrsvZET5OFXlbND O20/+jQbRY1F1kJOuzbP5UmR25N2JZmhMxlQ8r2XFft/2QHQEilF1bmKA77iwICA M5CQ2q5ag13BHFV7MNxRGvh3PoHRYU6AYUkdvJnXE2ICRsZTKZc04wDPSO6j06Pp NBkXcamhohfkHWsauwHHbDZHe8JWL60waspfrgBb9XyjQG5lDDVYJtzzXu/j5649 5RXwLiQOY30pqLPrsyQcFJK6ar9LQyOtuU/Q8ZWQMbyIG4Hbb8z4NInCgCF3XaWk bqgMqZblTW7SYyidVfuaicFGyKcxEnPzmJ7R08BCuEsHR6xOQcwFs2iuqcvsgfBu XMAbbpywHsEVj6YpuvBHEwCgbe9nY8Zm8m4ThnRFxTKSkHuEDK5M8lGTB5ueREj8 k3zEphlhCow3+eaGi9igzNqS9qqGM1ZQFF0hm3sluuTJLAiNM9zaqLA6iIpSt4+1 r9DRivZv =/oVn -END PGP SIGNATURE-
Re: No native packages?
On Mon, Feb 18, 2013 at 08:05:07PM +0100, Guillem Jover wrote: I was not attacking the NMU faith or its usefulness, otherwise we'd obviously not have NMUs; what I was getting at in this thread, that got trimmed in the quoted mail, is the thought that the current NMU procedure for native packages is bogus, as argumented previously. Oh, but I didn't mean to object to the fact that a specific procedure (the one used to NMU native packages) could be improved. I didn't quote that part simply because I didn't have anything to add/comment on that. Sorry for the misunderstanding, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: No native packages?
Gergely Nagy writes (Re: No native packages?): There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Making it harder and much much more inconvenient for downstream distributions to modify them is a *goal* in these cases: to make it harder to diverge from one another. I haven't looked up to see what these packages are, but I worry that what you are doing here is undermining the freedom of our downstreams. The ability of our users and downstreams to choose to modify the software we distribute is the core of their software freedom. As a project we should be making it easier, not harder, to produce modified derivatives. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20771.42201.4516.770...@chiark.greenend.org.uk
Re: No native packages?
In article 8738xju6br@windlord.stanford.edu, Russ Allbery r...@debian.org wrote: I'm still religious about using non-native packaging for my own packages that have any conceivable use outside of Debian or derivatives, since I find it aesthetically ugly, and therefore psychically painful, to make new releases for the rest of the world that contain only Debian packaging changes and therefore want the versioning space to make Debian-only changes without making a new non-Debian release. It's perfectly possible to release version 4.2.3 followed by 4.2.3-1 when you want to make the Debian-specific packaging change and then go back to the native 4.2.4 when you make the next not-just-Debian change. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20771.42672.416170.625...@chiark.greenend.org.uk
Re: No native packages?
Ian Jackson ijack...@chiark.greenend.org.uk writes: Gergely Nagy writes (Re: No native packages?): There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Making it harder and much much more inconvenient for downstream distributions to modify them is a *goal* in these cases: to make it harder to diverge from one another. I haven't looked up to see what these packages are, but I worry that what you are doing here is undermining the freedom of our downstreams. The two packages in question are dpatch and dh-exec, and yes, what I do with them could be considered as undermining the freedom of downstreams. However, in this two cases, I believe that is a good thing, as in the long run, neither we nor downstream should want to deviate from one an other. Why? Because if downstream introduces something there, and start to rely on it, while upstream the same thing does not get introduced, or does in a different way, everything that builds on either, will fall apart, and make it that much harder to work together. The ability of our users and downstreams to choose to modify the software we distribute is the core of their software freedom. As a project we should be making it easier, not harder, to produce modified derivatives. I agree, but to a limit. But there are tools that should be patched as little as possible, to preserve interoperability between distributions, and both dpatch and dh-exec are such tools that when they diverge in either down- or upstream, interoperability suffers. Want something included? Get it in upstream first, so things won't break. That is one of the reasons I kept both as native, and why I believe there is no compelling reason to change that. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5ek1brv.fsf@algernon.balabit
Re: No native packages?
]] Ian Jackson I haven't looked up to see what these packages are, but I worry that what you are doing here is undermining the freedom of our downstreams. They're free to do whatever they want. The ability of our users and downstreams to choose to modify the software we distribute is the core of their software freedom. As a project we should be making it easier, not harder, to produce modified derivatives. I'm part of an effort to make an OS, and while I'm happy the bits I create are useful in creating other OS-es, that's not the primary goal and not what I'm optimising for, so I disagree with what you're saying above. (Everything else being equal, I'll choose a solution that makes my downstream's lives easier, of course.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liakarkk@xoog.err.no
Re: No native packages?
On Sat, 2013-02-16 at 12:11:29 +0100, Stefano Zacchiroli wrote: On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote: (Random data point: I have 14 packages with versions indicating they are NMUed native packages installed on my system. Some of them have priority standard or higher.) I've a similar number on my system, but most of these appear to be from people that have not been active in the project for a while? Precisely, hence the usefulness of NMUs. In the interim when you don't know if those people have disappeared from the project (for all sort of valid reasons) or not, other developers can help using NMUs. That way they help both the maintainers in question, relieving some of their duties if they are gone only temporarily, and the project as a whole that avoids being technically stalled for a while. I was not attacking the NMU faith or its usefulness, otherwise we'd obviously not have NMUs; what I was getting at in this thread, that got trimmed in the quoted mail, is the thought that the current NMU procedure for native packages is bogus, as argumented previously. Even then, we do not consider long term maintenance of orphaned packages through QA uploads a good thing, so even more reason for this not to be done for dead native packages, which lots of maintainers might rely on. But, let me repeat, if this needs to be done anyway, then those changes should be clearly distinguished as not coming from the native package developer(s), by not taking over the upstream file releases and versionspace. When you don't know if the native package developer(s) have disappeared, well, you ask, and might want to consider doing the same we do with dead non-native upstream projects, also mentioned previously, which might include being offered to be added as co-upstream, an agreed handover, a fork if the developer(s) do not want to step aside, a transition of reverse dependencies to another package, or a possible upstream adoption (after some safe timespan) if the developer(s) have completely disappeared from the face of the earth. This did not appear to have been done with those currently NMUed native packages, hence my rethorical question. Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130218190507.gb3...@gaara.hadrons.org
Re: No native packages?
On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote: (Random data point: I have 14 packages with versions indicating they are NMUed native packages installed on my system. Some of them have priority standard or higher.) I've a similar number on my system, but most of these appear to be from people that have not been active in the project for a while? Precisely, hence the usefulness of NMUs. In the interim when you don't know if those people have disappeared from the project (for all sort of valid reasons) or not, other developers can help using NMUs. That way they help both the maintainers in question, relieving some of their duties if they are gone only temporarily, and the project as a whole that avoids being technically stalled for a while. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: No native packages?
On Mon, 2013-02-04 at 18:43:22 +0100, Jakub Wilk wrote: So what do you propose instead? It's not like native packages get NMUed because of great entertainment value of the NMU process, but because there's no better choice. The same thing we usually do when confronted with a dead upstream project. And in case the maintainer is active elsewhere in the project, has not replied to RC bugs nor possible intentions to NMU, and it's something that really needs fixing, then I think the current native NMU procedure (the upstream+nmuN stuff) is bogus and needs to be fixed, instead the package should be converted to a non-native one and a traditional NMU version used (something like upstream-0.N), as used to be the case before, so that the original tarball is preserved, and the changes distinguished from the upstream releases to make it clear what's what. (Random data point: I have 14 packages with versions indicating they are NMUed native packages installed on my system. Some of them have priority standard or higher.) I've a similar number on my system, but most of these appear to be from people that have not been active in the project for a while? Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130213024153.gb22...@gaara.hadrons.org
Re: No native packages?
* Guillem Jover guil...@debian.org, 2013-02-02, 13:56: if you are going to patch the package you might as well do the one line change from 3.0 (native) to 3.0 (quilt), and rename the source tarball to add «.orig». That's a good solution for derivatives, not so much for NMUs or backports. As I mentioned on my previous mail, I consider that a nice feature. To me NMUing or backporting a native package is the equivalent of an external and uninvolved person to send a mail to, say, the postgresql developers, telling them that you've released a new version of the upstream project for them... on the upstream server. Taking into account that the distribution archive and BTS are the hosting site for the native package, an NMU is a versionspace and file release takeover, and stomps over previously released versions and supercedes them, which might be confusing for downstreams (like non-derivatives), as the NMU might end up being rejected, or reimplemented in a different and incompatible way, etc. So what do you propose instead? It's not like native packages get NMUed because of great entertainment value of the NMU process, but because there's no better choice. (Random data point: I have 14 packages with versions indicating they are NMUed native packages installed on my system. Some of them have priority standard or higher.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130204174322.ga8...@jwilk.net
Re: No native packages?
On Fri, 2013-02-01 at 22:25:18 +0100, Jakub Wilk wrote: * Guillem Jover guil...@debian.org, 2013-01-29, 20:31: if you are going to patch the package you might as well do the one line change from 3.0 (native) to 3.0 (quilt), and rename the source tarball to add «.orig». That's a good solution for derivatives, not so much for NMUs or backports. As I mentioned on my previous mail, I consider that a nice feature. To me NMUing or backporting a native package is the equivalent of an external and uninvolved person to send a mail to, say, the postgresql developers, telling them that you've released a new version of the upstream project for them... on the upstream server. Taking into account that the distribution archive and BTS are the hosting site for the native package, an NMU is a versionspace and file release takeover, and stomps over previously released versions and supercedes them, which might be confusing for downstreams (like non-derivatives), as the NMU might end up being rejected, or reimplemented in a different and incompatible way, etc. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130202125646.ga4...@gaara.hadrons.org
Re: No native packages?
* Guillem Jover guil...@debian.org, 2013-01-29, 20:31: if you are going to patch the package you might as well do the one line change from 3.0 (native) to 3.0 (quilt), and rename the source tarball to add «.orig». That's a good solution for derivatives, not so much for NMUs or backports. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130201212518.ga8...@jwilk.net
Re: No native packages?
On Wed, 2013-01-30 at 17:58 +1100, Joey Hess wrote: Julien Cristau wrote: Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0 (git) format, why can't we simply make use of shallow cloning? At which point you have lost all the advantages of shipping the repository that Tollef mentioned, as far as I can tell. You're back to needing an external repository that's kept up to date if you ever need to get at the history. You can shallow clone at depth one each ref in the repository, which gets you all tags (filter to released versions to avoid needing any further license review). Is it also possible to say everything in branch A which isn't in branch B, so that you could include everything from the debian branch but not the upstream branch? That might be useful when you aren't 100% certain of the DFSG freeness of the upstream history, whereas you might well be happy that the versions incorporated into the debian branch were ok. Also, I wonder if it is possible to arrange that having unpacked a git format source package that the remotes for debian and upstream are already prepopulated in the repo such that git remotes update would fetch all of the missing history without having to git remotes add etc. Ian. -- Ian Campbell In Newark the laundromats are open 24 hours a day! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359535095.10403.14.ca...@dagon.hellion.org.uk
Re: No native packages?
On 01/29/2013 08:29 AM, Russ Allbery wrote: Benjamin Drung bdr...@debian.org writes: Other distributions gain from your extra work. Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? I'm not sure I see how it makes any difference. Either way, I would start with their package and add Debian packaging files for Debian. The only difference is some minor variation in what commands I run at the very start of that process (namely, git-import-dsc for a non-native package vs. git-import-orig for a native package). I have a hard time seeing how this choice would make more than thirty seconds of difference to my workflow. Well, this happened to me once (a package in Ubuntu), and I asked upstream to switch to non-native, which he did. The problem wasn't the work flow, but mainly tracking upstream version numbers. With a non-native, I can make the difference between packaging and non-packaging changes just by looking at the version number in Ubuntu, and I can even make a watch file to track it for me. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5108e928.10...@debian.org
Re: No native packages?
On 01/28/2013 08:59 PM, Gergely Nagy wrote: In my opinion, a native package is the wrong choice when your only arguments for it is convenience. That's not a strong argument To the contrary, I think that convenience of one or another format is the *only* argument. What you've listed as counter-argument are cases were it isn't convenient, IMO. And that's why we design packaging tools and format: so that they are convenient to use. I don't think you should feel bad because of that kind of laziness. I see it as an optimization of your work flaw rather than laziness (that's just different wording for the exact same idea in a more positive way). Also, I'm sorry but I don't buy your argument that newbies would see bad native-package examples and reproduce it. Anyone who looked a bit into -mentors@l.d.o (and I know you do) will be able to tell that they do use native packages anyway by simple mistake and lack of knowledge. Repeatedly, we have to explain anyway. Also, I don't understand why you think an NMU becomes awkward if it deals with a native package. Could you explain? On 01/28/2013 08:59 PM, Gergely Nagy wrote: There are good arguments *for* a native package, as Joey listed, and they can work well if upstream == maintainer. But as soon as that relationship breaks, for whatever reason, care needs to be taken both upstream and both in packaging to ensure a smooth transition. I've seen that fail before, though, not with native packages. I fail to understand why this would be a problem for the 2 native package I maintain (eg: debpear and openstack-pkg-tools). The new maintainer would just take over the work (as usual?)... Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5108e999.8030...@debian.org
Re: No native packages?
On 01/30/2013 04:38 PM, Ian Campbell wrote: Also, I wonder if it is possible to arrange that having unpacked a git format source package that the remotes for debian and upstream are already prepopulated in the repo such that git remotes update would fetch all of the missing history without having to git remotes add etc. Yeah, I would love to have this as well. Currently, I do: ./debian/rules get-vcs-source which adds upstream repository, does a git fetch upstream and create the orig.tar.xz for me. It's not as nice as what you describe (which I would like to have too), but it is a nice workaround. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51090cc6.5010...@debian.org
Re: No native packages?
On Tue, Jan 29, 2013 at 12:59:28AM +0100, Cyril Brulebois wrote: Benjamin Drung bdr...@debian.org (28/01/2013): Other distributions gain from your extra work. Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? “upstream first” anyone? Well, no. At least for me it has always been always upstream, eventually, i.e. every tier in software distribution shall strive to have their changes integrated upstream, eventually. Which is not quite the same as upstream *first*. The difference for me is relevant, because downstreams often have to *first* patch and distribute their own versions, due to schedule unalignment with their own upstreams. And then consolidate afterwards. And note that the matter of schedule is not only a matter of we have a really fast release cycle as, say, Ubuntu wrt Debian. Even in Debian we often face non reactive (to our standards) upstreams, and then have to patch our packages right away to make an upload, being able to have the patches integrated upstreams only much later. It's all relative, really, and depends on the time availability of the two peers at any upstream/downstream border. This is why I'm personally very much in favor of discouraging native packages wherever possible. With non-native packages, at least with current packaging technologies, patches are first class citizens. Downstreams can add a patch simply dropping a file in debian/. That then remains essentially the same throughout its lifetime. From inception (by downstream) to the moment it's forwarded either to us (Debian) or directly to the rightful last tier upstream. Whereas all this gets a little more complex with native packages. This is surely not an excuse that relieves downstreams of the moral duty of upstreaming their changes (moral duty that apply to Debian as well as anyone else, mind you). But I think it is in the interest of each upstreams (including ourselves) to make it as easy as possible for downstreams to first apply patches, according to their own schedule and needs, and then forward them upstream. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: No native packages?
Gergely Nagy, 2013-01-28 09:44:18 +0100 : [...] By harmful side effects, I mean two things: [...] - Patches not separated Not quite true. You can still have debian/patches/* and apply them at build-time (dpatch or quilt), even if they're not shipped in a separate .diff.gz file. Roland. -- Roland Mas The best definition of an immortal is someone who hasn't died yet. -- in Ye Gods! (Tom Holt) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obg8wg4c@polymir.internal.placard.fr.eu.org
Re: No native packages?
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. That would be useful, yes, but that's unrelated to a package being native or not. What I'm saying is, Debian source packages *must* be useful on their own aswell, for those corner cases where the VCS is not an appropriate place to turn to. (Provided there's a VCS at all, but that's another discussion again) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871ud45obi.fsf@algernon.balabit
Re: No native packages?
Wouter Verhelst wou...@debian.org writes: On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote: Wouter Verhelst wou...@debian.org writes: On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, There can only be too many of anything if it is (or can be) harmful in some way to have the thing in question. Perhaps not a convincing argument, but one of the main reasons I mightily dislike native packages for things that aren't Debian specific in any way, is because it sets a bad example. If you see native packages being abused for the sake of convenience, Doing something for the sake of convenience is not a bad thing. On the contrary; inconvenience is (terribly) bad for motivation and productivity. Doing something for the sake of convenience is not, in itself, a bad thing indeed. Even with native packages, if you know what you're doing, and you're careful, you're not doing any harm, either. However, that's you, with a ton of experience behind your back, and deep knowledge of Debian. Then someone comes along, looking for examples, and sees a growing number of native packages: Oh hey, this is easy, I'll do this too! And things go downhill from there. There *are* cases where native packages are inappropriate, and it is already a pain in the backside at times to convince people new to Debian that native packages do have unwelcome properties in certain cases. My belief is that Debian packages should not only be technically sound (which a lot of them already are), but should also set a good example for those who are looking for inspiration, for ideas. It is a bit more work for the packager, yes, but I've yet to see a case where the extra work would not be trivially scriptable to the point that one only needs to remember a command or two - which is, as far as I'm concerned, far below the annoying threshold. (I know counter examples must exist, but for the general case, I doubt that the debian-upstream split would be all that hard, not even in the long run.) it becomes that much easier to give in to temptation, and use native packaging even when it does have harmful side-effects. That's a recursive argument: You're trying to convince me that doing something is bad simply because doing it may cause us to do it more. But if I don't think that doing it more is a problem any more than doing that something in the first place is, you've not actually convinced me. Imagine gcc or the linux kernel being native packages then. By harmful side effects, I mean two things: - Awkward to NMU As I said in my previous mail, that's indeed a bug that should be fixed. Easily fixable by making the package non-native. - Patches not separated That's not a bug; it can be a feature, and even when it's not it can be argued that it's not a terrible issue. Packages should be in SCM, and you should have some form of communication with people who package work with your code. If you don't, you have a bigger problem than whether or not you're using native packages. That's a terribly sweet idea, but in practice, it doesn't work. If it would, I'd be the happiest person on earth. First of all, not all downstreams use an SCM (shocking, I know), and not all of them keep them up to date, especially if their SCM is located elsewhere than upstream's. I've seen both NMUs and downstream packages which were supposed to be in SCM, but the SCM was out of date. I'd love to trust downstream SCMs, but experience shows that rarely works, and my most stable point is whatever they have in their archive - and that's the Debian source package. I'd love if downstream talked to me directly, and sometimes they do, sometimes their SCM is even up-to-date, but most of the time, we talk in patches (which is also good, but what patches they send me, and what is in their archive often differs, as some patches are deemed 'unimportant' or 'irrelevant' for Debian - which they may be, but let me decide that, thankyouvermuch). In summary, yes, I have bigger problems than native packages, and that sucks, but native packages add insult to injury, because even if communication fails, I have a hard time inspecting what they do, because I lack the nicely separated patches. While separating patches is often seen as an inconvenience, a useless one at that in the world of SCMs, it does reduce the amount of space needed to store the result, it makes it easier to review the difference
Re: No native packages?
Roland Mas lola...@debian.org writes: Gergely Nagy, 2013-01-28 09:44:18 +0100 : [...] By harmful side effects, I mean two things: [...] - Patches not separated Not quite true. You can still have debian/patches/* and apply them at build-time (dpatch or quilt), even if they're not shipped in a separate .diff.gz file. How many native packages do that? And how is that less inconvenient than simply having a non-native package? -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwvs47oj.fsf@algernon.balabit
Re: No native packages?
Am Montag, den 28.01.2013, 22:53 -0600 schrieb Peter Samuelson: [Benjamin Drung] Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? If their native format is an archive in gzipped tar file format, like ours is, I'm not sure I would care, if I even _notice_, that there is packaging metadata for some other operating system in there. In fact it's not at all uncommon for upstream projects to ship .spec files, .vcproj files, and other platform-specific build infrastructure. Maybe you're thinking of the inconvenience of the top-level 'debian' directory, which is rather inflexible in that all Debian distributions and derivatives use the same path for their own use, but that ceased to be a problem several dpkg releases ago. Versioning is a problem for native packages. Which version will you give your upload to Debian? Using the same version number (with no Debian revision) will lead to the same version for your Debian package and the downstream distribution package, but despite the same version, the content of the tarball will be different (at least regarding the debian/ directory). -- Benjamin Drung Debian Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359484276.5427.6.camel@deep-thought
Re: No native packages?
Tollef Fog Heen tfh...@err.no writes: I wasn't trying to imply that my idea was new. :-) Sorry. :) I wasn't clear enough that I figured you probably knew the history. Yes, this is a lot of work, and I'm not sure what the best way to go about it would be. On the other hand, I think we're not actually shipping the real source if we're not shipping that metadata. The most useful definition of source I've seen is the «preferred format for modification» one, and if we need or prefer something outside the source package to do useful things with it (such as looking at what patches are applied, who wrote them and when), the source package is not the real source. Yes, definitely agreed. I would really like the model in which we just ship around Git repositories as our source. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehh3u8k6@windlord.stanford.edu
Re: No native packages?
On Sun, 2013-01-27 at 19:16:44 +0100, Jakub Wilk wrote: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I don't really see the problem here, if you are going to patch the package you might as well do the one line change from 3.0 (native) to 3.0 (quilt), and rename the source tarball to add «.orig». One of the issues with native packages before format 3.0, was that it required the downstream to choose a patching system, add the patching machinery to debian/rules and debian/control, etc, but this is now a trivial change. It could also be pretty inconvinient if the packaging had to diverge substantially as the debian/ directory would get in the way, this is also not an issue anymore with format 3.0. I was a very strong proponent of avoiding native packages for non-Debian-and-derivatives specific software, because it used to be a real burden for downstreams, but not so any longer. Now I just think that while it might be convenient, it's just bad style (and I'm guilty of this myself, as I've not yet converted libpmount to non-native, for example). For Debian-specific software, the point of native packages is that at least the Debian (or any other derivative) archive and BTS are the upstream releases and bugs site for that software, so turning those into non-native, to me would mean having to look for external project hosting sites for them. It's not only about derivatives, but also in-Debian forking, i.e. NMUs. NMUing native packages is quite awkward. TBH, I've always found that to be a feature of the Debian procedures. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129193152.ga11...@gaara.hadrons.org
Re: No native packages?
Guillem Jover guil...@debian.org writes: I don't really see the problem here, if you are going to patch the package you might as well do the one line change from 3.0 (native) to 3.0 (quilt), and rename the source tarball to add «.orig». One of the issues with native packages before format 3.0, was that it required the downstream to choose a patching system, add the patching machinery to debian/rules and debian/control, etc, but this is now a trivial change. It could also be pretty inconvinient if the packaging had to diverge substantially as the debian/ directory would get in the way, this is also not an issue anymore with format 3.0. I was a very strong proponent of avoiding native packages for non-Debian-and-derivatives specific software, because it used to be a real burden for downstreams, but not so any longer. Now I just think that while it might be convenient, it's just bad style (and I'm guilty of this myself, as I've not yet converted libpmount to non-native, for example). +1. If you're using a Git-based workflow, or anything equivalent, you can easily merge in changes to the upstream's debian packaging files and do all the other things you might want to do in pretty much exactly the same way whether the package is native or non-native, including dropping patches into debian/patches. It just doesn't matter very much any more. It's mildly harder if you're working outside of any VCS, but not really that much. Mostly it's a touch harder to merge subsequent upstream changes to the debian packaging files if you're not using a VCS. I'm still religious about using non-native packaging for my own packages that have any conceivable use outside of Debian or derivatives, since I find it aesthetically ugly, and therefore psychically painful, to make new releases for the rest of the world that contain only Debian packaging changes and therefore want the versioning space to make Debian-only changes without making a new non-Debian release. But I don't see any point for packages that exist solely within the Debian world (kerberos-configs, for instance). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738xju6br@windlord.stanford.edu
Re: No native packages?
Julien Cristau wrote: Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0 (git) format, why can't we simply make use of shallow cloning? At which point you have lost all the advantages of shipping the repository that Tollef mentioned, as far as I can tell. You're back to needing an external repository that's kept up to date if you ever need to get at the history. You can shallow clone at depth one each ref in the repository, which gets you all tags (filter to released versions to avoid needing any further license review). joey@gnu:~/srcgit clone --depth 1 --bare --no-single-branch file://`pwd`/debhelper debhelper.shallow Cloning into bare repository 'debhelper.shallow'... remote: Counting objects: 7372, done. remote: Compressing objects: 100% (4336/4336), done. remote: Total 7372 (delta 3760), reused 5854 (delta 2629) Receiving objects: 100% (7372/7372), 2.70 MiB | 1007 KiB/s, done. Resolving deltas: 100% (3760/3760), done. joey@gnu:~/src/debhelper.shallowgit log --oneline 9.20120909 d27f027 releasing version 9.20120909 893119b Update French translation git-clone needs to be fixed to allow specifiying --depth 0, which currently includes the full history, rather than only the head of each branch. -- see shy jo signature.asc Description: Digital signature
Re: No native packages?
On 01/28/2013 07:30 PM, Philip Hands wrote: You're going to have to do a lot better than saying that you don't like it very much if you're going to convince me that Joey's mistaken in that choice Hi Phil, Thanks for sharing your view (and the one of Joe). I also maintain at least one native package: debpear, which is a helper to build some PHP PEAR packages. So I do think it makes sense in some cases. I would really like to hear others thoughts about this choice. Is there counter arguments for this kind of package? Oh, and I allmost forgot as well: openstack-pkg-tools is native too (but it's not in testing, just in experimental until Wheezy is out). I don't think it would need any change in derivatives, IMO, especially because they don't need an upstart job to replace an init script which doesn't exist in these packages. However, I don't really feel 100% confident about these choices, and would happily read external opinions. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5108c524.9030...@debian.org
Re: No native packages?
Wouter Verhelst wou...@debian.org writes: On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, There can only be too many of anything if it is (or can be) harmful in some way to have the thing in question. Perhaps not a convincing argument, but one of the main reasons I mightily dislike native packages for things that aren't Debian specific in any way, is because it sets a bad example. If you see native packages being abused for the sake of convenience, it becomes that much easier to give in to temptation, and use native packaging even when it does have harmful side-effects. By harmful side effects, I mean two things: - Awkward to NMU - Patches not separated While separating patches is often seen as an inconvenience, a useless one at that in the world of SCMs, it does reduce the amount of space needed to store the result, it makes it easier to review the difference between two versions. Granted, one can look at the SCM repository, but there are times when that's far more work than paging through a set of diffs: ie, comparing two versions of a Debian package. If there are diffs, that's easy. If I have to turn to an SCM, I have to figure out its setup (and hope it is documented, which it often is not), and trust that tags and whatnot does reflect what is in the package. That trust is something I do not have, as I've seen it too many times that downstream package and downstream SCM branch did not agree. In an ideal world, this wouldn't be an issue, but we're not living in that world yet. In short, too many native packages, even if they're used in situations where they do not immediately become a problem, does set a bad example, and serves as an excuse to use them even when they're inappropriate. So, for the sake of prospective maintainers, I'd love to get the number of these packages down. While I agree that in some cases it might be a bad idea to package something as a native package, for trivial things (like my package fdpowermon), this isn't a big deal; and the overhead of having to deal with an upstream tarball and/or upstream build system etc is just not worth it. We have tools that make it easy to create upstream tarballs from an SCM repo. Git has git archive, gitpkg and possibly other tools make it very easy to create upstream tarballs: so much so, that it means nothing more than tagging the repo properly. I've been using this for quite a while for some of my packages (ivykis, libmongo-client), and it doesn't need neither an upstream build system, nor much thought once it is set up. (And setup is fairly trivial too) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5fd66jh.fsf@algernon.balabit
Re: No native packages?
On 27 January 2013 18:32, Gergely Nagy alger...@balabit.hu wrote: Jakub Wilk jw...@debian.org writes: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, though I doubt you'll find (m)any supporters of the idea of banning them completely. There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Making it harder and much much more inconvenient for downstream distributions to modify them is a *goal* in these cases: to make it harder to diverge from one another. As for no DEP-3? I do sincerely hope that by 2013, everyone's using a VCS, and we can pick patches from there. If only we all can agree on the VCS to use. A patch seems to be the common denominator. Also, there are a lot of caveats with DVSC. I have seen a lot of repositories where maintainers forgot to push commits and/or tags. Or obsolete Vcs-* headers, because repository got moved, yet there was no upload yet. And that's easy to do, since the thing you upload to ftp doesn't check/require for you to push anything. NMUs security uploads are often also missing from Vcs-* repositories. Native packages is a social issue =) my view is that they set a bad example and introduce a lot of do this, unless it's native package. Also some of the convenience stated, benefits Debian, but hurts dowstream. As any packaging change, triggers a new .orig.tar.gz with a new checksum. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjqBX8k=ddrlhpufddj_6q3dsfvmiaj_vc_xepvhf-...@mail.gmail.com
Re: No native packages?
Gergely Nagy alger...@balabit.hu writes: ... We have tools that make it easy to create upstream tarballs from an SCM repo. Git has git archive, gitpkg and possibly other tools make it very easy to create upstream tarballs: so much so, that it means nothing more than tagging the repo properly. I've been using this for quite a while for some of my packages (ivykis, libmongo-client), and it doesn't need neither an upstream build system, nor much thought once it is set up. (And setup is fairly trivial too) So to summarise your argument appears to be that it sets a bad example (which is only a valid criticism if you manage to show why it's a bad idea in the first place) and that you don't like people not using all the same tools you use. If the person doing the packaging is the upstream, you're asking them to pretend to be two people, and decide when a patch is debian specific or not, and then learn a load of tools that they have no use for in order to keep their personality neatly split. I know a couple of upstreams who use native packages for their stuff, and I'm pretty sure one or both of them would give up if we insisted that they add unnecessary and confusing extra steps to their workflow. Currently they just incorporate the debian directory into their tree, add a couple of steps to their release Makefile target, and whenever they release a new version, it's ready for Debian too. Another example is Joey Hess (I know that ikiwiki is native, so is git-annex, as are (IIRC) some others of his -- feel free to look them up). You're going to have to do a lot better than saying that you don't like it very much if you're going to convince me that Joey's mistaken in that choice -- particularly since he comes up with pretty decent arguments in the opposite direction -- see his answer here: http://ask.debian.net/questions/does-native-package-needs-to-be-debian-specific-if-upstrean-author-is-a-mantainer Cheers, Phil. P.S. that answer from Joey took me seconds to find -- I find it astonishing that some people in this thread seem to be starting from their assumption that it is a hard-and-fast about native packages being exclusive to Debian, and proceeding straight to trying to stop the naughty transgressors without doing a moment's fact checking first, or even bothering to come up with a cogent argument to justify their assumption. Certainly there seems to have been no acknowledgement that there are good examples available that break that rule. On the other hand, it's pretty obvious that one will be able to point to examples where the package clearly should not be native, but that doesn't tell one much about the general case -- this thread seems to boil down to: Look, here's a bad thing, therefore all things are bad. I'm sure we could be spending our time more productively. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpXLUSmdykFf.pgp Description: PGP signature
Re: No native packages?
On the other side of the fence are folks who believe in the separation between upstream and Debian so much that they refuse to package software they are upstream for (I'm not among them, but I know they exist). -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FM0QaX-Y64YFzAYMj=s8z-ibvtjkrsfyhpb2c0ro7...@mail.gmail.com
examples for better-not-native packages was: No native packages?
Let's start to collect examples of package which we might should rather not be native. This might make the discussion easier. - maven-repo-helper, maven-debian-helper both packages contain a lot of logic that would also be usefull for other distributions, e.g. fedora. However the code needs a lot of cleanup. I hope the following is a useful command to search native packages: aptitude search ?source-version(^[^-]+$) -F %p %V %d of to narrow the search to installed packages aptitude search ?installed ?source-version(^[^-]+$) -F %p %V %d Even the narrowed search to installed packages reveals a few packages which makes me wonder why they're native: awesome-extra 2012061101 additional modules for awesome dvcs-autosync 0.5Automatically synchronize ... emacs-goodies-el35.3 Miscellaneous add-ons for Emacs fdpowermon 1.7simple battery power monitor git-annex 3.20130124 manage files with git github-backup 1.20120627 backs up data from GitHub hardlink0.3.0~rc1 Hardlinks multiple copies ... ikiwiki 3.20121212 a wiki compiler jarwrapper 0.43 Run executable Java .jar files laptop-detect 0.13.7 attempt to detect a laptop maven-ant-helper7.7helper scripts for building ... metainit0.0.5 Generates init scripts mr 1.13 Multiple Repository management tool netmask 2.3.12 helps determine network masks os-prober 1.57 utility to detect other OSes ... pristine-tar1.26 regenerate pristine tarballs ssft0.9.13 Shell Scripts Frontend Tool whois 5.0.20 intelligent WHOIS client xtrlock 2.2Minimal X display lock program This list makes me wonder whether it's really worth the effort that Joey separates upstream and debian version of his packages? Regards, Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301281342.54927.tho...@koch.ro
Re: No native packages?
Philip Hands p...@hands.com writes: Gergely Nagy alger...@balabit.hu writes: ... We have tools that make it easy to create upstream tarballs from an SCM repo. Git has git archive, gitpkg and possibly other tools make it very easy to create upstream tarballs: so much so, that it means nothing more than tagging the repo properly. I've been using this for quite a while for some of my packages (ivykis, libmongo-client), and it doesn't need neither an upstream build system, nor much thought once it is set up. (And setup is fairly trivial too) So to summarise your argument appears to be that it sets a bad example (which is only a valid criticism if you manage to show why it's a bad idea in the first place) and that you don't like people not using all the same tools you use. No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. Exceptions exist, and three cheers for them! Only if they weren't the exceptions... If the person doing the packaging is the upstream, you're asking them to pretend to be two people, and decide when a patch is debian specific or not, and then learn a load of tools that they have no use for in order to keep their personality neatly split. If the change is under debian/, then it is debian specific, otherwise it is not. That's a reasonable rule of thumb, and doing just this would entirely satisfy me. Doesn't need a personality split, in my opinion. There's also the case where upstream and debian maintainer are the same *now*, but that can change anytime. Case in point: there's a package[1] in Debian where upstream maintainer used to be the same, but not anymore. Nevertheless, for hysterical reasons, upstream is still shipping a debian/ dir, an outdated and crappy one, which, from time to time, still confuses the hell out of people who download the original tarball. That sucks. It's an upstream problem, but it wouldn't have happend in the first place, if packaging upstream work weren't tied together so tightly in the past. [1]: syslog-ng Anyway, I'll expand on this later, see the end of my mail. I know a couple of upstreams who use native packages for their stuff, and I'm pretty sure one or both of them would give up if we insisted that they add unnecessary and confusing extra steps to their workflow. What steps would be confusing? Currently they just incorporate the debian directory into their tree, add a couple of steps to their release Makefile target, and whenever they release a new version, it's ready for Debian too. Instead of adding a few steps to my release target, I have a script that checks out the debian branch, merges master, and dch -i. It's about 5 lines long, and pretty much the same thing as a Makefile target. I could also wire it into a release target, if I had one. It's neither confusing, nor any extra work, apart from about 5 minutes spent on thinking about the workflow, once. You're going to have to do a lot better than saying that you don't like it very much if you're going to convince me that Joey's mistaken in that choice -- particularly since he comes up with pretty decent arguments in the opposite direction -- see his answer here: http://ask.debian.net/questions/does-native-package-needs-to-be-debian-specific-if-upstrean-author-is-a-mantainer I don't want to convince you that Joey is mistaken, for he is not. There's nothing inherently wrong with native packages, and there are plenty of cases where they make sense (I maintain two native packages myself, there's no possible way to convince me they should be made non-native), Joey has strong arguments for him handling his packages native, and I agree with him on that. But the same arguments don't hold for everyone. Certainly there seems to have been no acknowledgement that there are good examples available that break that rule. I beg to differ: http://lists.debian.org/debian-devel/2013/01/msg00588.html Perhaps I should've phrased it differently, but I believe my message there was quite clear nevertheless. On the other hand, it's pretty obvious that one will be able to point to examples where the package clearly should not be native, but that doesn't tell one much about the general case -- this thread seems to boil down to: Look, here's a bad thing, therefore all things are bad. I don't know where you got that from. Most of us posting in this thread have expressed that native packages aren't the problem, their abuse is. In my reading, it boils down to: Look, here's a bad thing, and bad things are spreading. Lets stop the bad things. Granted, we didn't really explain what that abuse is, so let me try to do that! * In my opinion, a native package is always a wrong choice when upstream and debian maintainer are not the same. This is still the case
Re: No native packages?
]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txq15lcx@xoog.err.no
Re: No native packages?
Gergely Nagy algernon at balabit.hu writes: There's also the case where upstream and debian maintainer are the same *now*, but that can change anytime. Case in point: there's a package[1] That’s actually (one of) the reasons why I’m not using native packages for the software I’m upstream of, or working closely with upstream. And I know of lots of DDs who do the same. (And I’ve non-native-ised a number of packages, too.) It should probably not be a requirement but more than a suggestion. And it *did* turn out that some software written and packaged for Debian was, in the end, used on other systems… I was surprised. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130128t180122-...@post.gmane.org
Re: No native packages?
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. Yes, many of us would like that, which is why it's been repeatedly discussed at Debconfs, but no one has come up with a good solution to the fact that this requires reviewing the entire VCS archive for DFSG-freeness and rewriting history if any non-free code is ever introduced in it. (Or, well, changing the requirements we have around source package freeness, but that seems less likely.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boc92or6@windlord.stanford.edu
Re: No native packages?
On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. Yes, many of us would like that, which is why it's been repeatedly discussed at Debconfs, but no one has come up with a good solution to the fact that this requires reviewing the entire VCS archive for DFSG-freeness and rewriting history if any non-free code is ever introduced in it. (Or, well, changing the requirements we have around source package freeness, but that seems less likely.) Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0 (git) format, why can't we simply make use of shallow cloning? We only distribute a single revision, the one we're building, and if the history is polluted for whatever reason, it has no impact--we're only providing the equivalent of a tarball. The difference being, there's nothing preventing anyone receiving the package from adding the appropriate remotes and restoring the full history (at their choice), so it retains its utility. From the POV of review, it's then no different to a plain tarball. But from the POV of a developer, I can fetch the history, add remotes, commit changes, push to somewhere and open pull requests, etc.. At least for schroot, both the source and release are all in git, so making the release tarball is nowadays a single git archive. Having the ability to use 3.0 (git) would allow the use of a git workflow throughout with zero intermediately formats like tar. To get more back on topic, all the packages I maintain in Debian are non-native. It's more flexible, and it encourages separation of upstream and debian releases, even when Debian /is/ the upstream. So changes to the actual package content go into proper upstream releases, and you have the option to make as many Debian revisions as necessary. It makes things easier for derivatives and external users. I don't think there's any real difference in the amount of effort it takes to do non-native releases, and I can't see any compelling reason for native releases other than history. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128181720.gj29...@codelibre.net
Re: No native packages?
On 28 January 2013 18:17, Roger Leigh rle...@codelibre.net wrote: On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. Yes, many of us would like that, which is why it's been repeatedly discussed at Debconfs, but no one has come up with a good solution to the fact that this requires reviewing the entire VCS archive for DFSG-freeness and rewriting history if any non-free code is ever introduced in it. (Or, well, changing the requirements we have around source package freeness, but that seems less likely.) Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0 (git) format, why can't we simply make use of shallow cloning? We How many revisions does one need to shallow clone to have an .orig. tree and a debian tree? As one commonly still wants to see what changes are applied if any. If the answer is 2 and git can diff them, than it's great. (Or 3 to include pristine-tar delta?! do we still care about pristine-tar at this point?!) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhmTL45FVNXkJe-DCwSr8E=nnmdvvem0yaadjpg1kc...@mail.gmail.com
Re: No native packages?
Roger Leigh rle...@codelibre.net writes: Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0 (git) format, why can't we simply make use of shallow cloning? We only distribute a single revision, the one we're building, and if the history is polluted for whatever reason, it has no impact--we're only providing the equivalent of a tarball. The difference being, there's nothing preventing anyone receiving the package from adding the appropriate remotes and restoring the full history (at their choice), so it retains its utility. From the POV of review, it's then no different to a plain tarball. But from the POV of a developer, I can fetch the history, add remotes, commit changes, push to somewhere and open pull requests, etc.. My impression of the previous discussion is that the perceived benefits of shallow clones weren't enough to do the work if all we were going to use was just the minimal shallow clone, since at that point there seemed to be little to gain for the user over using debcheckout, but the ftp team still has to enforce the restrictions on shallow clones, deal with source packages with more revisions than expected, etc. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87libd17wz@windlord.stanford.edu
Re: No native packages?
On Mon, Jan 28, 2013 at 18:17:20 +, Roger Leigh wrote: On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. Yes, many of us would like that, which is why it's been repeatedly discussed at Debconfs, but no one has come up with a good solution to the fact that this requires reviewing the entire VCS archive for DFSG-freeness and rewriting history if any non-free code is ever introduced in it. (Or, well, changing the requirements we have around source package freeness, but that seems less likely.) Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0 (git) format, why can't we simply make use of shallow cloning? At which point you have lost all the advantages of shipping the repository that Tollef mentioned, as far as I can tell. You're back to needing an external repository that's kept up to date if you ever need to get at the history. Cheers, Julien signature.asc Description: Digital signature
Re: No native packages?
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: I am guilty myself of maintaining a native package (and another one is waiting in NEW). However, I will be happy to switch to a non-native format once I figure out a releasing work-flow that is convenient for me. Changing from native packages to non-native sounds like increasing my work-load for absolutely no gain to Debian (or myself). Harder to merge downstream changes? How? We know how to merge patches don't we? I do double-releases for other stuff; its a pain but for those cases essential. I don't recommend it if you don't need to. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128214934.ga14...@enc.com.au
Re: No native packages?
Am Dienstag, den 29.01.2013, 08:49 +1100 schrieb Craig Small: On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: I am guilty myself of maintaining a native package (and another one is waiting in NEW). However, I will be happy to switch to a non-native format once I figure out a releasing work-flow that is convenient for me. Changing from native packages to non-native sounds like increasing my work-load for absolutely no gain to Debian (or myself). Other distributions gain from your extra work. Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? -- Benjamin Drung Debian Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359413996.4795.2.camel@deep-thought
Re: No native packages?
Benjamin Drung bdr...@debian.org (28/01/2013): Other distributions gain from your extra work. Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? “upstream first” anyone? Mraw, KiBi. signature.asc Description: Digital signature
Re: No native packages?
On Mon, Jan 28, 2013 at 11:59:56PM +0100, Benjamin Drung wrote: Other distributions gain from your extra work. Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? If I want it enough I'm not going to care. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129002044.ga25...@enc.com.au
Re: No native packages?
Benjamin Drung bdr...@debian.org writes: Other distributions gain from your extra work. Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? I'm not sure I see how it makes any difference. Either way, I would start with their package and add Debian packaging files for Debian. The only difference is some minor variation in what commands I run at the very start of that process (namely, git-import-dsc for a non-native package vs. git-import-orig for a native package). I have a hard time seeing how this choice would make more than thirty seconds of difference to my workflow. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obg8x24j@windlord.stanford.edu
Re: No native packages?
On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote: Wouter Verhelst wou...@debian.org writes: On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, There can only be too many of anything if it is (or can be) harmful in some way to have the thing in question. Perhaps not a convincing argument, but one of the main reasons I mightily dislike native packages for things that aren't Debian specific in any way, is because it sets a bad example. If you see native packages being abused for the sake of convenience, Doing something for the sake of convenience is not a bad thing. On the contrary; inconvenience is (terribly) bad for motivation and productivity. it becomes that much easier to give in to temptation, and use native packaging even when it does have harmful side-effects. That's a recursive argument: You're trying to convince me that doing something is bad simply because doing it may cause us to do it more. But if I don't think that doing it more is a problem any more than doing that something in the first place is, you've not actually convinced me. By harmful side effects, I mean two things: - Awkward to NMU As I said in my previous mail, that's indeed a bug that should be fixed. - Patches not separated That's not a bug; it can be a feature, and even when it's not it can be argued that it's not a terrible issue. Packages should be in SCM, and you should have some form of communication with people who package work with your code. If you don't, you have a bigger problem than whether or not you're using native packages. While separating patches is often seen as an inconvenience, a useless one at that in the world of SCMs, it does reduce the amount of space needed to store the result, it makes it easier to review the difference between two versions. Granted, one can look at the SCM repository, but there are times when that's far more work than paging through a set of diffs: ie, comparing two versions of a Debian package. If there are diffs, that's easy. If there aren't diffs, running debdiff isn't hard. It's true that if the code has diverged a lot, figuring out the individual, separate changes that are applied to the original code can be a hard job. However, before that becomes a problem, the code itself needs to be sufficiently large (it's pretty hard to lose track of the changes made to a package containing a single script of, say, a few hundred lines of code). As I said before, I'm not advocating that you would maintain a sufficiently large codebase as a native package. So in the situations that I think native packages make sense, this isn't actually an issue. (and to give you an idea of what I consider to be sufficiently large, I've never been tempted to repackage nbd as a native package, even though I could, which is... wouter@carillon:~/code/c/nbd$ wc -l *.h *.c 168 cliserv.h 201 config.h 19 lfs.h 82 nbd.h 24 netdb-compat.h 94 make-integrityhuge.c 682 nbd-client.c 2781 nbd-server.c 1320 nbd-tester-client.c 115 nbd-trdump.c 5486 total ... well, not very large either) [...] While I agree that in some cases it might be a bad idea to package something as a native package, for trivial things (like my package fdpowermon), this isn't a big deal; and the overhead of having to deal with an upstream tarball and/or upstream build system etc is just not worth it. We have tools that make it easy to create upstream tarballs from an SCM repo. Git has git archive, gitpkg and possibly other tools make it very easy to create upstream tarballs: so much so, that it means nothing more than tagging the repo properly. It's not just about creating it, but also about it not being worth it. I've been using this for quite a while for some of my packages (ivykis, libmongo-client), and it doesn't need neither an upstream build system, Well, if you're not doing an upstream build system, then you're not providing anything beyond your Debian package. The net result is that you're not doing anything that couldn't be done by way of a native package too, while lying to potential non-Debian downstreams that you're considering their use case too. That's just silly. If you don't have an upstream build system, you only have a package. If you only have a package, it should be a native package, and not have a non-functional upstream tarball, because that is evil. -- Copyshops should do
Re: No native packages?
[Benjamin Drung] Image the opposite. You want to package a software that is only available in a downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a non-native format or a native format? If their native format is an archive in gzipped tar file format, like ours is, I'm not sure I would care, if I even _notice_, that there is packaging metadata for some other operating system in there. In fact it's not at all uncommon for upstream projects to ship .spec files, .vcproj files, and other platform-specific build infrastructure. Maybe you're thinking of the inconvenience of the top-level 'debian' directory, which is rather inflexible in that all Debian distributions and derivatives use the same path for their own use, but that ceased to be a problem several dpkg releases ago. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129045301.gr4...@p12n.org
Re: No native packages?
]] Russ Allbery Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. It sounds like you are arguing that we should just ship the the repository in the source package, then. No chance of it ever getting out of date, trivial to find the merge points and missing patches between two packages and fits much better with a VCS-driven workflow. Yes, many of us would like that, which is why it's been repeatedly discussed at Debconfs, but no one has come up with a good solution to the fact that this requires reviewing the entire VCS archive for DFSG-freeness and rewriting history if any non-free code is ever introduced in it. I wasn't trying to imply that my idea was new. :-) Yes, this is a lot of work, and I'm not sure what the best way to go about it would be. On the other hand, I think we're not actually shipping the real source if we're not shipping that metadata. The most useful definition of source I've seen is the «preferred format for modification» one, and if we need or prefer something outside the source package to do useful things with it (such as looking at what patches are applied, who wrote them and when), the source package is not the real source. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ni04jw4@xoog.err.no
No native packages?
Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, though I doubt you'll find (m)any supporters of the idea of banning them completely. It's not only about derivatives, but also in-Debian forking, i.e. NMUs. NMUing native packages is quite awkward. I am guilty myself of maintaining a native package (and another one is waiting in NEW). However, I will be happy to switch to a non-native format once I figure out a releasing work-flow that is convenient for me. [0] http://planet.debian.org/#http://blog.surgut.co.uk/2013/01/thoughts-on-debian-package-policies.html -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130127181644.ga6...@jwilk.net
Re: No native packages?
Jakub Wilk jw...@debian.org writes: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, though I doubt you'll find (m)any supporters of the idea of banning them completely. There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Making it harder and much much more inconvenient for downstream distributions to modify them is a *goal* in these cases: to make it harder to diverge from one another. As for no DEP-3? I do sincerely hope that by 2013, everyone's using a VCS, and we can pick patches from there. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87libemq8v.fsf@algernon.balabit
Re: No native packages?
Hi, On 27.01.2013 19:32, Gergely Nagy wrote: There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Not knowing your use cases in particular, it would often be good enough if we could restrict native packages to use cases, where they actually were designed for. We have native packages in Debian where people deliberately use them, because they are more convenient (i.e. less strict) and easier to use (no need for orig tarballs). I don't think we should endorse that any further, so I agree with Jakub in that. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: No native packages?
Arno Töll a...@debian.org writes: Hi, On 27.01.2013 19:32, Gergely Nagy wrote: There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Not knowing your use cases in particular, it would often be good enough if we could restrict native packages to use cases, where they actually were designed for. Completely agreed. We have native packages in Debian where people deliberately use them, because they are more convenient (i.e. less strict) and easier to use (no need for orig tarballs). I don't think we should endorse that any further, so I agree with Jakub in that. Perhaps we should figure out how to make it easier to create orig tarballs (though, gitpkg does a pretty good job there, imo), and prod the native (ab)users to see how their workflow can be made easier even with non-native packaging. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehh6mnv1.fsf@algernon.balabit
Re: No native packages?
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: Dmitrijs Ledkovs wrote on his blog[0]: Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches. I would tend to agree that we have too many native packages, There can only be too many of anything if it is (or can be) harmful in some way to have the thing in question. I've yet to see a convincing argument why using native packages would be harmful in any way. The argument about merging patches doesn't convince me, at all; mostly because downloading a source package and inspecting it isn't what I would consider an interesting way to communicate with downstreams. Instead, I'd hope they talk to me, or put their stuff in a SCM repository somewhere (all my packages are), or some such. While I agree that in some cases it might be a bad idea to package something as a native package, for trivial things (like my package fdpowermon), this isn't a big deal; and the overhead of having to deal with an upstream tarball and/or upstream build system etc is just not worth it. though I doubt you'll find (m)any supporters of the idea of banning them completely. It's not only about derivatives, but also in-Debian forking, i.e. NMUs. NMUing native packages is quite awkward. That's a bug then, which we should fix. Banning native packages isn't a fix, however, it's a copout. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130127214939.gk31...@grep.be
Re: Of the use of native packages for programs not specific to Debian.
Jonathan Yu jonathan.i...@gmail.com writes: I agree that debian/ files likely don't cause a whole lot of trouble to us (it should only be a line to remove it using debian/rules prior to building? but I'm not 100% sure on that). However, I don't think that it not being tremendously burdensome on us in Debian is sufficient justification to permit or encourage this behaviour. On Wed, Sep 16, 2009 at 4:41 AM, Goswin von Brederlow goswin-...@web.de wrote: Wouter Verhelst wou...@debian.org writes: On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems I don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things. And that quickly goes away when upstream accepts patches that fix their debian directory. I am both the upstream maintainer of several Perl modules, for which I am also one of the Debian package maintainers. I personally am just pragmatic, and provide only what is necessary at various points -- so, upstream packages contain what is necessary to install via the standard Perl-ish way (CPAN shell), and the Debian packages contain this plus some Debian-specific stuff. One of the issues I would have with putting debian/ files upstream (beyond just being unexpected by the user since it's probably very uncommon in the wild) is that I would need to sync changes that the other pkg-perl team members submit, since we maintain packages as a team. It just seems a whole lot of work for little gain. But that is because you have 2 seperate repositories. One for upstream and one for the debian perl team. You are upstream but the debian-perl team is the maintainer. That you are also a member of the debian-perl team is just a coincidence muddying the waters. So I don't think your case falls under the upstream == maintainer case. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all. Debian packages from the Debian distribution usually are policy-compliant and maintained, so this kind of problem does not manifest itself as often for our downstreams And as we were talking about packages where the debian maintainer is also upstream this problem also doesn't manifest for Debian itself. (of course there are packages that are not maintained nor policy-compliant, but then they don't tend to live long in the distribution). And the problem is that users really don't know which is which, so upstream is just being a jerk and confusing their users :). Not to mention that it would reflect badly on our packages in Debian, as people would say, damn Debian packages, this one wouldn't even build, it sucks!!! I think someone (tm) should do a study and see just how difficult it is to deal with debian/ files in an upstream tarball. I take it that our scripts probably handle this sort of thing transparently, or that the effected files are removed prior to build time. If upstream == maintainer then why would there ever be an upstream release without a debian release? If you have done all the work of fixing bugs or adding features and released a new version then running debsign + dupload is really not complicated. I would assume people would always do that for releases. Maybe not for dev snapshots, they might just be for testing prior to uploads. But then those should be clearly recognisable as such. It takes verry little effort to use a clear versioning scheme. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Goswin von Brederlow goswin-...@web.de writes: If upstream == maintainer then why would there ever be an upstream release without a debian release? It's rare for there to be an upstream release without a Debian release, although it can happen during freezes or with frequent dev releases. It's very, very common for there to be a Debian release without an upstream release, which is more where the problem is. Going through all the normal upstream release process when there was just a minor change to the packaging files is really a waste of time, and then what happens is that there's a temptation to not fix packaging problems until one gets around to making another upstream release. I went through all this with my own packages for which I'm upstream and found that keeping the packaging separate from the upstream distribution was way more convenient and useful for me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
On Wed, Sep 23 2009, Russ Allbery wrote: Goswin von Brederlow goswin-...@web.de writes: If upstream == maintainer then why would there ever be an upstream release without a debian release? It's rare for there to be an upstream release without a Debian release, although it can happen during freezes or with frequent dev releases. It's very, very common for there to be a Debian release without an upstream release, which is more where the problem is. Going through all the normal upstream release process when there was just a minor change to the packaging files is really a waste of time, and then what happens is that there's a temptation to not fix packaging problems until one gets around to making another upstream release. I went through all this with my own packages for which I'm upstream and found that keeping the packaging separate from the upstream distribution was way more convenient and useful for me. And that, I think, may serve as a guiding criteria for whether one should make a package native or not. With my native packages (kernel-package, ucf, and devotee), I do not _have_ an upstrem process, nor an upstream distribution or tarball; and thus there is no difference in process for a packaging change or a feature addition -- which makes it clear to me that these are native packages. So if the upstream release has a life of its own, distinct from a Debian package upload, you probably do not want native packaging even if you, as a DD, are upstream. manoj -- Gee, Toto, I don't think we're in Kansas anymore. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Manoj Srivastava wrote: And that, I think, may serve as a guiding criteria for whether one should make a package native or not. With my native packages (kernel-package, ucf, and devotee), I do not _have_ an upstrem process, nor an upstream distribution or tarball; and thus there is no difference in process for a packaging change or a feature addition -- which makes it clear to me that these are native packages. Whenever you guys bring the argument of convenience to make a package native, I imagine that RedHat, Novell and company did the same with half of GNOME packages, and I had to look at Fedora and SuSE's pages checking for updates, report bugs in their bugzillas, look if a new upstream version only changed the spec file or also the code, and I want to cry myself to sleep. Emilio signature.asc Description: OpenPGP digital signature
Re: Of the use of native packages for programs not specific to Debian.
On Wed, Sep 23 2009, Emilio Pozuelo Monfort wrote: Manoj Srivastava wrote: And that, I think, may serve as a guiding criteria for whether one should make a package native or not. With my native packages (kernel-package, ucf, and devotee), I do not _have_ an upstrem process, nor an upstream distribution or tarball; and thus there is no difference in process for a packaging change or a feature addition -- which makes it clear to me that these are native packages. Whenever you guys bring the argument of convenience to make a package native, I imagine that RedHat, Novell and company did the same with half of GNOME packages, and I had to look at Fedora and SuSE's pages checking for updates, report bugs in their bugzillas, look if a new upstream version only changed the spec file or also the code, and I want to cry myself to sleep. I think you have not looked at the details of what I said: very little of my argument has to do with convenience; it has to do with artifacts of a separate upstream entity. If the package does exist as an upstream entity, it will be reflected in the processs; and the lack of such a process (having an upstream tarball that is available separate from the debian upload, for instance) serves as a hint. Convenience has little to do with it. manoj ps: The new devotee package, for instance, is unlikely to remain a debian native, since it would make sense to have it not tied only to debian. Again, convenience does not enter the equation. -- linux: the choice of a GNU generation (k...@cis.ufl.edu put this on Tshirts in '93) Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Giacomo A. Catenazzi c...@debian.org writes: Wouter Verhelst wrote: On Thu, Sep 17, 2009 at 07:46:08AM +0200, Giacomo A. Catenazzi wrote: On native package the debian/changelog is also used for upstream changelog: upstreams tend to package their packages as native. [...] Thus non debian specific package, which are also native, should (must on GPL licensed packages) have a separate upstream changelog. That doesn't follow. You're assuming it's going to be impossible to keep the original debian/changelog file, and/or that the only way to package something that an upstream has packaged as native is to package it as non-native. hmm. Do you think we should pack an external package as native, if upstream (or upstream distribution) packages it as native? If you can join the upstream team and do releases directly as the upstream you then are then why not? I think this is not intended by our polict, but OTOH it is the easier way: we should only take care about version conflicts (automatically adding a suffix could not be enough on few seldom cases). But if we pack as non-native (as it should be: we are not upstream), more problems arises: we cannot patch anymore debian directory: on 3.0 source format the original debian dir will disappear, thus removing the debian/changelog (which is required by GPL for upstream changes). How does that work at all for upstream itself? From what you describe unpacking the upstream released source with dpkg-source -x would end up without debian dir at all. It is not impossible to solve this problem: we can manually copy the original changelog to our diff/patches. So the question is: Is it really worth to use native package for programs not specific to Debian ? Is it worth it use non-native when you are upstream and maintainer? I think that is the more important question. For packages where upstream != maintainer you should imho not use native format. If upstream releases debian packages (has a debian dir) and the maintainer also releases debian packages then there will be problems. That can only be avoided by close cooperation. Become co-upstreams / co-maintainers and only release one version. I still think it is not nice for downstream. It is not nice either way. Worse for downstream of downstream. If I'm an upstream and a Debian maintainer for a particular package, and a downstream distribution wants to modify my package, then I think it's fairly reasonable for them to just modify the package, without having to repackage it entirely. This is the problem with sources 3.0, on non-native packages: we cannot modify the package, we must repack discarding all original files in debian/ Why? Only problem I see is that you need to duplicate the files from debian/ if you change from native to non-native. The solution is to get upstream to fix their debian dir so you do not have to modify the package under normal circumstances. And in an emergency you modify it as native package. People fork software *all the time*. This is no different. Yes, but it is not our job to fork packages (freely interpreted from devref 3.5). ciao cate MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Charles Plessy wrote: Le Fri, Sep 18, 2009 at 12:51:14AM +0200, Wouter Verhelst a écrit : What I'm trying to discuss here is that Debian Developers who package their own software as Debian native packages should be allowed to do so Hi Wouter and everybody, it seems to me that the difficulties in this discussion come from the fact that ’native’ is used to mean two different things: - Packages using a dpkg format called ‘native’. - Software made by Debian for Debian. No, I don't think so, because this was the core of discussion (see the subject). But I think there was some confusion because I started this sub-thread as question of debian/ directory on upstream, thus having Debian as downstream distribution (and interpreting upstream as upstream distribution) Wouter takes the more orthodox interpretation, where we don't have any upstream distribution. I still think that converting a (non debian specific) package into native package is not nice to downstreams, and probably egoistic (= debian centric). But anyway it is not a big issue, so I don't think we should continue discussing it. Every developer will decide if going native or not. [ My mails in this week was about a new possible problem that I discovered, but it is more about dpkg-source 3.0 then the native format ] This creates confusion, as there are arguments in favor of using the format called ‘native’ for software not specific to Debian, but on the othe hand there is a general perception that if a package uses a native format, the software has special ties to Debian. Interestingly, when the format ‘3.0 (git)’ will be accepted in our archive, there may be a lot of ‘native’ programs that will be using a non-native package format. AFAIK the only supported format will be 3.0 (native), 3.0 (quilt). The other 3.0 format were considered experimental and discouraged. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
On Thu, Sep 17, 2009 at 07:46:08AM +0200, Giacomo A. Catenazzi wrote: On native package the debian/changelog is also used for upstream changelog: upstreams tend to package their packages as native. [...] Thus non debian specific package, which are also native, should (must on GPL licensed packages) have a separate upstream changelog. That doesn't follow. You're assuming it's going to be impossible to keep the original debian/changelog file, and/or that the only way to package something that an upstream has packaged as native is to package it as non-native. If I'm an upstream and a Debian maintainer for a particular package, and a downstream distribution wants to modify my package, then I think it's fairly reasonable for them to just modify the package, without having to repackage it entirely. People fork software *all the time*. This is no different. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
On Thu, Sep 17, 2009 at 09:25:39AM +0200, Giacomo A. Catenazzi wrote: But if we pack as non-native (as it should be: we are not upstream), more problems arises: we cannot patch anymore debian directory: on 3.0 source format the original debian dir will disappear, thus removing the debian/changelog (which is required by GPL for upstream changes). What kind of insane upstream that is not debian would put upstream change log in the *debian*/changelog file ? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Sigh. On Thu, Sep 17, 2009 at 09:25:39AM +0200, Giacomo A. Catenazzi wrote: Wouter Verhelst wrote: That doesn't follow. You're assuming it's going to be impossible to keep the original debian/changelog file, and/or that the only way to package something that an upstream has packaged as native is to package it as non-native. hmm. Do you think we should pack an external package as native, if upstream (or upstream distribution) packages it as native? No, of course not. Please don't put any words in my mouth. What I'm trying to discuss here is that Debian Developers who package their own software as Debian native packages should be allowed to do so, if they know what the downsides are. That is not even remotely similar to upstreams doing the wildest things. I've said so multiple times now. [...] People fork software *all the time*. This is no different. Yes, but it is not our job to fork packages (freely interpreted from devref 3.5). I didn't even come close to saying that. When downstreams change a Debian-native package, they are in fact forking our software. That is what I was referring to with the above-quoted sentence. However, that is not the same, nor does it even remotely have anything to do, with Debian Developers forking upstream software. Of course, if someone packages software for Debian as a native package, doing so will encourage downstreams to fork their software. That is one of the downsides of packaging software natively, and again, this should be documented; but there's nothing inherently wrong with that. If an upstream were to say that a Debian Developer should stop sending them patches, and that they instead should just develop their own version, then that, perhaps, would be somewhat similar. If you really must have an upstream analogy. Now, can you please stop twisting this discussion into insanity? -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Of the use of native packages for programs not specific to Debian.
Le Fri, Sep 18, 2009 at 12:51:14AM +0200, Wouter Verhelst a écrit : What I'm trying to discuss here is that Debian Developers who package their own software as Debian native packages should be allowed to do so Hi Wouter and everybody, it seems to me that the difficulties in this discussion come from the fact that ’native’ is used to mean two different things: - Packages using a dpkg format called ‘native’. - Software made by Debian for Debian. This creates confusion, as there are arguments in favor of using the format called ‘native’ for software not specific to Debian, but on the othe hand there is a general perception that if a package uses a native format, the software has special ties to Debian. Interestingly, when the format ‘3.0 (git)’ will be accepted in our archive, there may be a lot of ‘native’ programs that will be using a non-native package format. Maybe the problem could simply solved by renaming one of the two concepts? Native format could be called ‘direct’, or native packages could be called ’original’, for instance. This would help the Project to keep track of what programs it is upstream for. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Wouter Verhelst wou...@debian.org writes: On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems I don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things. And that quickly goes away when upstream accepts patches that fix their debian directory. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all. Debian packages from the Debian distribution usually are policy-compliant and maintained, so this kind of problem does not manifest itself as often for our downstreams And as we were talking about packages where the debian maintainer is also upstream this problem also doesn't manifest for Debian itself. (of course there are packages that are not maintained nor policy-compliant, but then they don't tend to live long in the distribution). MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
I agree that debian/ files likely don't cause a whole lot of trouble to us (it should only be a line to remove it using debian/rules prior to building? but I'm not 100% sure on that). However, I don't think that it not being tremendously burdensome on us in Debian is sufficient justification to permit or encourage this behaviour. On Wed, Sep 16, 2009 at 4:41 AM, Goswin von Brederlow goswin-...@web.de wrote: Wouter Verhelst wou...@debian.org writes: On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems I don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things. And that quickly goes away when upstream accepts patches that fix their debian directory. I am both the upstream maintainer of several Perl modules, for which I am also one of the Debian package maintainers. I personally am just pragmatic, and provide only what is necessary at various points -- so, upstream packages contain what is necessary to install via the standard Perl-ish way (CPAN shell), and the Debian packages contain this plus some Debian-specific stuff. One of the issues I would have with putting debian/ files upstream (beyond just being unexpected by the user since it's probably very uncommon in the wild) is that I would need to sync changes that the other pkg-perl team members submit, since we maintain packages as a team. It just seems a whole lot of work for little gain. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all. Debian packages from the Debian distribution usually are policy-compliant and maintained, so this kind of problem does not manifest itself as often for our downstreams And as we were talking about packages where the debian maintainer is also upstream this problem also doesn't manifest for Debian itself. (of course there are packages that are not maintained nor policy-compliant, but then they don't tend to live long in the distribution). And the problem is that users really don't know which is which, so upstream is just being a jerk and confusing their users :). Not to mention that it would reflect badly on our packages in Debian, as people would say, damn Debian packages, this one wouldn't even build, it sucks!!! I think someone (tm) should do a study and see just how difficult it is to deal with debian/ files in an upstream tarball. I take it that our scripts probably handle this sort of thing transparently, or that the effected files are removed prior to build time. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Goswin von Brederlow wrote: Wouter Verhelst wou...@debian.org writes: On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems I don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things. And that quickly goes away when upstream accepts patches that fix their debian directory. I don't see that as a *lot* of work at all. It just means you need a good relationship with upstream so changes to the debian dir are merged upstream quickly. If you have write access to upstreams RCS then I don't see this as a problem at all. Yes, but I use cdbs for my packages, and I don't want to force upstream to use the same tools. But now I've found an other problem: On native package the debian/changelog is also used for upstream changelog: upstreams tend to package their packages as native. But I'll pack it as normal package. With the 3.0 source format the upstream changelog (if it is in debian) will be removed (which could maybe is a problem with the GPL licenses: we distribute in the sources the changelog, but we hide/delete it, when unpacking). Thus non debian specific package, which are also native, should (must on GPL licensed packages) have a separate upstream changelog. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Goswin von Brederlow wrote: I also would rather have a native package in Debian and then have Debian derivatives convert the package using Debians tar.gz as orig.tar.gz and put their derivate specific changes into diff.gz. Shipping a source with 0 byte diff.gz in Debian seems stupid and shipping a all of debian/ as diff.gz in Debian means the changes derivatives do get lost in a huge diff. Seems to me like a native package in Debian and non-native in a derivative is the best way. We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems (if they do something more than a raw copy of our sources). If we pack non debian-specific packages as native, I'll have more trouble in explaining upstreams that it is bad to ship debian/ dir. [I'm really waiting for dpkg-source 3.0 for this reason!] And derivatives will have more difficulties if they want to change the helper (to dh 7, to cdbs, ...). ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote: We have a lot of troubles when upstreams ship a debian/ directory in upstream tarball, thus I'll expect derivatives will have similar problems I don't see it that way. The reason why we have 'a lot of troubles' when upstreams ship a debian/ directory, is because upstreams usually supply that directory as a courtesy to make life 'easier' for those people who want to build a Debian package out of their SCM repository, and that as a result, they are usually not even remotely Policy-compliant. Thus, we need to do a *lot* of work to get them integrated properly; and any files that keep lying around in debian/ might interfere with other things. Debian packages from the Debian distribution usually are policy-compliant and maintained, so this kind of problem does not manifest itself as often for our downstreams (of course there are packages that are not maintained nor policy-compliant, but then they don't tend to live long in the distribution). -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Charles Plessy: At least one of the consequences of being native is that the package gets all its gettext and manpages translations for free from Debian. In the case of programs like ikiwiki [..] AFAIK, any translator from Debian who has translated ikiwiki's gettext or underlays (no man page translations ever contributed) has done so in the knowledge that it is not specific to Debian. Gunnar Wolf: Do you want to throw stones in the way of Debian derivatives by being unable to do packaging-specific changes while keeping track of your upstream releases? I see our most modification-happy derivative, Ubuntu, frequently modify native packages, with apparent success. I've never seen them or anyone reach for debhelper's --ignore flag, but it is there in case there is some file in debian/ that the derivative does not want used. -- see shy jo, who maintains non-debian-specific native packages including alien, etckeeper, filters, ikiwiki, jetring, moreutils, mpdtoys, mr, pdmenu, pristine-tar, sleepd, wmbattery; and prefers not to deal with source format 1.0 non-native packages. signature.asc Description: Digital signature
Re: Of the use of native packages for programs not specific to Debian.
Joey Hess jo...@debian.org writes: Charles Plessy: At least one of the consequences of being native is that the package gets all its gettext and manpages translations for free from Debian. In the case of programs like ikiwiki [..] AFAIK, any translator from Debian who has translated ikiwiki's gettext or underlays (no man page translations ever contributed) has done so in the knowledge that it is not specific to Debian. Gunnar Wolf: Do you want to throw stones in the way of Debian derivatives by being unable to do packaging-specific changes while keeping track of your upstream releases? I see our most modification-happy derivative, Ubuntu, frequently modify native packages, with apparent success. I've never seen them or anyone reach for debhelper's --ignore flag, but it is there in case there is some file in debian/ that the derivative does not want used. I also would rather have a native package in Debian and then have Debian derivatives convert the package using Debians tar.gz as orig.tar.gz and put their derivate specific changes into diff.gz. Shipping a source with 0 byte diff.gz in Debian seems stupid and shipping a all of debian/ as diff.gz in Debian means the changes derivatives do get lost in a huge diff. Seems to me like a native package in Debian and non-native in a derivative is the best way. Now that all changes with the 3.0 formats. Then the could have: upstream.tar.gz debian.tar.gz derivative.diff.gz or upstream.tar.gz derivative.diff.gz That makes native or non-native in Debian equaly usefull to get changes back from derivatives. It is just a matter of making their build scripts build the right source packages. Something Debian could help teach dpkg-source. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Of the use of native packages for programs not specific to Debian.
Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit : I know it is fancy and modern to think that Debian native packages should only be used for things that are specific to the Debian infrastructure, but there is nothing in policy that requires that, and indeed several packages (including, e.g., offlineimap) are distributed as such. Hi Wouter, At least one of the consequences of being native is that the package gets all its gettext and manpages translations for free from Debian. In the case of programs like ikiwiki made by somebody who gave a lot to Debian, it is for sure a good thing, but in the case when the package maintainer sits on the translations, like for sbackup, this is clearly a problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Charles Plessy ple...@debian.org writes: Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit : I know it is fancy and modern to think that Debian native packages should only be used for things that are specific to the Debian infrastructure, but there is nothing in policy that requires that, To be clear (and I know you probably already know this): just because some practice is not explicitly mentioned in Policy, does not mean there is no good way to decide whether or not it's good practice. As far as whether this idea is “modern”, I don't know whether “more than 8 years” is outside that range for an operating system only 16 years old, but the consensus on this 2001-01 ‘debian-mentors’ thread URL:http://lists.debian.org/debian-mentors/2001/01/msg00191.html seems to be that packages should be native only if the package is specific to the Debian infrastructure. At least one of the consequences of being native is that the package gets all its gettext and manpages translations for free from Debian. Another one is that any change to the Debian packaging for the work can't be released without bumping the version number of the work, even when there's no other change in the work other than the Debian packaging. -- \ “The manager has personally passed all the water served here.” | `\ —hotel, Acapulco | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
On Fri, Sep 04, 2009 at 01:31:40AM +1000, Ben Finney wrote: Charles Plessy ple...@debian.org writes: Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit : I know it is fancy and modern to think that Debian native packages should only be used for things that are specific to the Debian infrastructure, but there is nothing in policy that requires that, To be clear (and I know you probably already know this): just because some practice is not explicitly mentioned in Policy, does not mean there is no good way to decide whether or not it's good practice. True. However, if something is not explicitly forbidden by Policy (and this isn't), and it does not cause (obvious) harm to Debian as a whole (which this doesn't), there is no good reason why people should pretend it's a bad idea. As far as whether this idea is “modern”, I don't know whether “more than 8 years” is outside that range for an operating system only 16 years old, but the consensus on this 2001-01 ‘debian-mentors’ thread URL:http://lists.debian.org/debian-mentors/2001/01/msg00191.html seems to be that packages should be native only if the package is specific to the Debian infrastructure. That thread has four people stating the downsides of making a package a native package; however, several of them also explicitly state the opinion that making a package native is perfectly okay, after having considered those downsides. That's pretty much what I was saying in my previous mail. As an aside, even if the thread did say something else, and with all due respect, I do not consider -mentors to be authoritative on such a subject. At least one of the consequences of being native is that the package gets all its gettext and manpages translations for free from Debian. Another one is that any change to the Debian packaging for the work can't be released without bumping the version number of the work, even when there's no other change in the work other than the Debian packaging. That's all most certainly true. I never said that making a package of which one is both Debian and upstream maintainer a native package is a good idea in _all_ cases. Indeed, my own such package, the nbd utilities, is not a native package, precisely because I do not consider it to be a good idea in that specific case for many of the reasons mentioned. What I am saying is that there can be cases where making a package a native package can be the right thing to do, even if the functionality of the package has nothing to do with Debian infrastructure. That it should be the choice of the maintainer to be able to do so. That deciding whether or not something should be a native package is the maintainer's prerogative, and nobody else's. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Of the use of native packages for programs not specific to Debian.
Wouter Verhelst wrote: On Fri, Sep 04, 2009 at 01:31:40AM +1000, Ben Finney wrote: Charles Plessy ple...@debian.org writes: Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit : I know it is fancy and modern to think that Debian native packages should only be used for things that are specific to the Debian infrastructure, but there is nothing in policy that requires that, To be clear (and I know you probably already know this): just because some practice is not explicitly mentioned in Policy, does not mean there is no good way to decide whether or not it's good practice. True. However, if something is not explicitly forbidden by Policy (and this isn't), and it does not cause (obvious) harm to Debian as a whole (which this doesn't), there is no good reason why people should pretend it's a bad idea. This sounds very wrong, as if it would be ok to cause harm to some part of Debian when it's not forbidden in Policy. I also don't agree that there are no good reasons why it's a bad idea. As far as whether this idea is “modern”, I don't know whether “more than 8 years” is outside that range for an operating system only 16 years old, but the consensus on this 2001-01 ‘debian-mentors’ thread URL:http://lists.debian.org/debian-mentors/2001/01/msg00191.html seems to be that packages should be native only if the package is specific to the Debian infrastructure. That thread has four people stating the downsides of making a package a native package; however, several of them also explicitly state the opinion that making a package native is perfectly okay, after having considered those downsides. That's pretty much what I was saying in my previous mail. Yes, though only after considering all the downsides, including having these discussions and people requesting you to reconsider from time to time. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
On Thu, Sep 03, 2009 at 10:04:49PM +0200, Luk Claes wrote: Wouter Verhelst wrote: True. However, if something is not explicitly forbidden by Policy (and this isn't), and it does not cause (obvious) harm to Debian as a whole (which this doesn't), there is no good reason why people should pretend it's a bad idea. This sounds very wrong, as if it would be ok to cause harm to some part of Debian when it's not forbidden in Policy. Hmm. I don't know how, but you somehow managed to read the exact opposite in my words of the message I was trying to deliver :-) [...] native package; however, several of them also explicitly state the opinion that making a package native is perfectly okay, after having considered those downsides. That's pretty much what I was saying in my previous mail. Yes, though only after considering all the downsides, including having these discussions and people requesting you to reconsider from time to time. Sure. I feel I should point out that my initial mail in this subthread was a reaction to a one-line statement that 'switching upstreams does not make a package native.' That I objected to, because of the lack of context, and the inherent feeling that, to me, seemed to be part of this message that this package had no business whatsoever of being a native package. I did not (and do not) defend making _this particular_ package a native one (I don't know enough about it either way), but was trying to discuss the more general issue here. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Of the use of native packages for programs not specific to Debian.
Wouter Verhelst wou...@debian.org writes: I feel I should point out that my initial mail in this subthread was a reaction to a one-line statement that 'switching upstreams does not make a package native.' That I objected to, because of the lack of context, and the inherent feeling that, to me, seemed to be part of this message that this package had no business whatsoever of being a native package. I didn't read that comment that way. Rather I read that switching upstream developer *by itself* is insufficient reason to make a package native. (I agree with that position.) You don't seem to have argued against that. Rather, you've presented the position that there are particular reasons that are sufficient for a package to be native. That's compatible with a position that switching upstreams is not one of those reasons, so I don't see what you object to. -- \ “I got an answering machine for my phone. Now when someone | `\ calls me up and I'm not home, they get a recording of a busy | _o__) signal.” —Steven Wright | Ben Finney pgpMDypM4v5ZM.pgp Description: PGP signature
debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Package: debian-policy Version: 3.8.3.0 Severity: wishlist User: debian-pol...@packages.debian.org Usertags: normative issue Hi, Currently, there is some ambiguity in the areas of version numbering, debian_revision, native packages, and requirement for a diff.gz/orig.tar.gz files in a source package. Also, currently policy does not carve out version name spaces for NMU's (native and non-native packages), for version numbers for binary only uploads, though there are well established practices for these use cases. To recap, this is what is incontrovertibly stated in policy: ,[ §5.6.12: `Version' ] | The format is: | [epoch`:']upstream_version[`-'debian_revision] | upstream_version | SNIP | The comparison behavior of the package management system with | respect to the upstream_version is described below. The | upstream_version portion of the version number is mandatory. | | The upstream_version may contain only alphanumerics[1] and the | characters `.' `+' `-' `:' `~' (full stop, plus, hyphen, colon, | tilde) and should start with a digit. If there is no | debian_revision then hyphens are not allowed; if there is no | epoch then colons are not allowed. | | debian_revision | This part of the version number specifies the version of the | Debian package based on the upstream version. It may contain | only alphanumerics and the characters `+' `.' `~' (plus, full | stop, tilde) and is compared in the same way as the | upstream_version is. | | It is optional; if it isn't present then the upstream_version | may not contain a hyphen. This format represents the case where | a piece of software was written specifically to be turned into a | Debian package, and so there is only one debianisation of it | and therefore no revision indication is required. ` Additionally, § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if applicable § C.1.1. `dpkg-source' states that it creates a diff.gz if appropriate, and looks at the diff.gz while extracting if applicable. ,[ § C.3. Source packages as archives ] | Original source archive - `package_upstream-version.orig.tar.gz' | This is a compressed (with `gzip -9') `tar' file containing the | source code from the upstream authors of the program. | | Debianisation diff - `package_upstream_version-revision.diff.gz' | This is a unified context diff (`diff -u') giving the changes | which are required to turn the original source into the Debian | source. These changes may only include editing and creating | plain files. The permissions of files, the targets of symbolic | links and the characteristics of special files or pipes may not | be changed and no files may be removed or renamed. | | All the directories in the diff must exist, except the `debian' | sub-directory of the top of the source tree, which will be created | by `dpkg-source' if necessary when unpacking. | | The `dpkg-source' program will automatically make the | `debian/rules' file executable (see below). | | If there is no original source code - for example, if the package is | specially prepared for Debian or the Debian maintainer is the same as | the upstream maintainer - the format is slightly different: then there | is no diff, and the tar file is named `package_version.tar.gz', and | preferably contains a directory named `package-version'. ` Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file -- Given that, it would be nice we could carve out a space in the version numbering that would help us distinguish NMU's and binary uploads. 1) dch --nmu adds +nmu1 for native packages 2) +nmuX is already supported by devscripts and lintian. 3) the developers reference also advocates adding +codename\d+. It also advocates using exactly the same tar.gz file as already in the archive. 4) this is how debhelper, cdbs, and my packaging scripts handle it. Please also look at the discussion below, which led
Re: Version numbering for security uploads of native packages
On 2008-03-16, Adam D. Barratt [EMAIL PROTECTED] wrote: On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote: The current binNMU numbering scheme was selected explicitly to allow security uploads to sort later by numbering as last_version+releaseserial; e.g., 1.2-5.1+etch1. That makes sense, although doesn't seem to match current practice. Was any consideration given as to where NMUs of native packages should sort? (I realise that they're the only case that doesn't automagically dtrt with respect to the numbering scheme). We'll adapt our practise to use +etchX for security updates. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
Gunnar Wolf [EMAIL PROTECTED] writes: At some point in 2006, a serious flaw is addressed via a NMU, so it sits at 1.0+sarge1. I still cannot be bothered to take a look at the damn package. Time passes. In March 2008 it (again) shows it needs to be taken care of, and you kindly prepare a new NMU, properly labeling it 1.0+etch1. It gets rejected, as it is a lower version. how about having it uploaded as 1.0+sarge1+etch1. looks funny, but actually follows the policy that says to 'append' +etch1 to such uploads. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
Bas Wijnen wrote: On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote: Bas Wijnen [EMAIL PROTECTED] writes: We have other ways of tracking that information than the version, though. Yes, and I don't really care, I just think going from +s1+nmu1 to +s2 seems to be doing things that it doesn't (revert the NMU). Strange reasoning as 1.0-0.1 followed by 1.1 is also not reverting an NMU perse... So we should go for +deb31[+]_1 or something? To make it clear again: +deb is a fixed part which means this is a security upload Or any other stable upload, yes? Yes, sorry. I forgot that those exist as well. :-) Why are we bothering to make something up if everyone is using etchnr etc? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
Luk Claes [EMAIL PROTECTED] writes: Bas Wijnen wrote: Yes, sorry. I forgot that those exist as well. :-) Why are we bothering to make something up if everyone is using etchnr etc? 1.0-1sarge1 1.0-1etch1. We don't have this problem currently because 1.0-1etch1 1.0-1lenny1, but we will again at some point in the future, and it would be nice to resolve it once and for all. Using something based on the Debian release version has the advantage that the version always increases from release to release. The code names bounce all over the place in version sorting space. And the original problem that sparked this thread is that devscripts is now using 1.0+nmu1 for NMUs of native packages and we're trying to figure out what version number should be used for security and/or stable uploads of native packages so that they sort properly. It would be nice if we could use the same convention for both native and non-native packages. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Wed, Mar 19, 2008 at 07:54:46PM +0100, Luk Claes wrote: Bas Wijnen wrote: On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote: Bas Wijnen [EMAIL PROTECTED] writes: We have other ways of tracking that information than the version, though. Yes, and I don't really care, I just think going from +s1+nmu1 to +s2 seems to be doing things that it doesn't (revert the NMU). Strange reasoning as 1.0-0.1 followed by 1.1 is also not reverting an NMU perse... Except that 1.1 is a MU unlike a security upload. One can expect that a decision was made about including (or not) the NMU in the next MU upload. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Version numbering for security uploads of native packages
Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]: Yes, sorry. I forgot that those exist as well. :-) Why are we bothering to make something up if everyone is using etchnr etc? 1.0-1sarge1 1.0-1etch1. We don't have this problem currently because 1.0-1etch1 1.0-1lenny1, but we will again at some point in the future, and it would be nice to resolve it once and for all. Using something based on the Debian release version has the advantage that the version always increases from release to release. The code names bounce all over the place in version sorting space. Umh... With release cycles close to 18 months, this would mean tha, being I a bad and lazy maintainer, I didn't touch my native package for over three years. Say, version 1.0 was released with Sarge, in 2005. At some point in 2006, a serious flaw is addressed via a NMU, so it sits at 1.0+sarge1. I still cannot be bothered to take a look at the damn package. Time passes. In March 2008 it (again) shows it needs to be taken care of, and you kindly prepare a new NMU, properly labeling it 1.0+etch1. It gets rejected, as it is a lower version. I have not touched the package for three years at last. Tell me, don't you think this should trigger some QA alarms? At very least, I'd agree with you uploading 1.~1+etch1. That way, when I'm finally done with my Precious 1.1 release, I can still properly upload it without any fuzz. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
Gunnar Wolf [EMAIL PROTECTED] writes: Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]: 1.0-1sarge1 1.0-1etch1. We don't have this problem currently because 1.0-1etch1 1.0-1lenny1, but we will again at some point in the future, and it would be nice to resolve it once and for all. Using something based on the Debian release version has the advantage that the version always increases from release to release. The code names bounce all over the place in version sorting space. Umh... With release cycles close to 18 months, this would mean tha, being I a bad and lazy maintainer, I didn't touch my native package for over three years. Say, version 1.0 was released with Sarge, in 2005. At some point in 2006, a serious flaw is addressed via a NMU, so it sits at 1.0+sarge1. I still cannot be bothered to take a look at the damn package. Time passes. In March 2008 it (again) shows it needs to be taken care of, and you kindly prepare a new NMU, properly labeling it 1.0+etch1. It gets rejected, as it is a lower version. I have not touched the package for three years at last. Tell me, don't you think this should trigger some QA alarms? At very least, I'd agree with you uploading 1.~1+etch1. That way, when I'm finally done with my Precious 1.1 release, I can still properly upload it without any fuzz. Sure, and this is why we haven't seen much problem with this. I think I remember only seeing one of these between sarge and etch. But there was one, and since it's a simple problem to solve by picking a somewhat more predictable versioning scheme, it seems worth the minor effort. There are packages where the only updates between two releases are for minor things like standards-version or Vcs and Homepage headers that aren't horribly vital. They're rare, but they do exist. I've not uploaded a new version of sident since the etch release, for example, and while I plan to do so when I have time to clean up some minor stuff, nothing would be fundamentally broken about it if I didn't. It's less likely that this would happen in combination with non-maintainer or non-unstable updates that would provoke this versioning, but I can see it happening. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On Sun, Mar 16, 2008 at 06:40:25PM +, Adam D. Barratt wrote: On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: [...] Good idea. Even better, IMO, would be to use a system which is in line with non-native packages. How about this rule: [using X.1] IMO this solution is slightly better than +nmu1, because it makes versions of native and non-native packages more uniformly mangled. However, any solution is better than no solution. :-) That does seem the most logical suggestion thus far. I dislike this approach because it makes it impossible for tools like Lintian to recognize NMUs of native packages and perform other NMU-specific checks (such as making sure an appropriate changelog entry is present). There's no way of knowing whether a native package with a version number of 1.2.1 is an NMU or not. Indeed. Luk already pointed out on irc that this is the (or at least a) reason .1 wasn't suggested by DevRef. Ok, that makes sense. However, with +nmu1, there still is the problem of how to name security uploads. With +s1, they sort after +nmu1, which I think is wrong. But we're talking about uploads to stable and testing anyway, so the +etch1 and similar version extensions are used. Do we want to solve the bug that they can have incorrect order? They should at least start with +X, where X is 'b' and 'n', if they want to sort correctly with respect to binNMUs and source NMUs. I like the +nmuN approach. devscripts 2.10.19 including +nmuN was uploaded earlier this evening. Good. That fixes all problems except the security versions[1]. Obviously a solution would be to add +debianversion.counter, where version should be anything that sorts correctly, such as the current stable version with testing added if the upload is to testing. This does perhaps result in versions which are longer than anyone would want, though (like 1.7.5+nmu3+debian3.1testing.1). Turning debian into deb and testing into + would make it better 1.7.5+nmu3+deb3.1+.1 is comparable in length to the current 1.7.5+nmu3+lenny1 Thanks, Bas [1] I'm working on a proposal to reformulate the devref section on NMUs. Since there seems to be consensus about using +nmuX, I'll include it in the proposal. If you don't agree that there is consensus, please say so. :-) -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Version numbering for security uploads of native packages
Bas Wijnen wrote: On Sun, Mar 16, 2008 at 06:40:25PM +, Adam D. Barratt wrote: On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: [...] Good idea. Even better, IMO, would be to use a system which is in line with non-native packages. How about this rule: [using X.1] IMO this solution is slightly better than +nmu1, because it makes versions of native and non-native packages more uniformly mangled. However, any solution is better than no solution. :-) That does seem the most logical suggestion thus far. I dislike this approach because it makes it impossible for tools like Lintian to recognize NMUs of native packages and perform other NMU-specific checks (such as making sure an appropriate changelog entry is present). There's no way of knowing whether a native package with a version number of 1.2.1 is an NMU or not. Indeed. Luk already pointed out on irc that this is the (or at least a) reason .1 wasn't suggested by DevRef. Ok, that makes sense. However, with +nmu1, there still is the problem of how to name security uploads. With +s1, they sort after +nmu1, which I think is wrong. But we're talking about uploads to stable and testing anyway, so the +etch1 and similar version extensions are used. Do we want to solve the bug that they can have incorrect order? They should at least start with +X, where X is 'b' and 'n', if they want to sort correctly with respect to binNMUs and source NMUs. I did not see any comments about Raphael's proposition (that seems better to me): Raphael Hertzog wrote: On Sun, 16 Mar 2008, Thijs Kinkhorst wrote: There may not be a good solution since MU's, NMU's and security uploads can currently be interleaved in any particular order, so it seems hard to make a scheme that would work reliably. It's possible, you just have to put the increment number before the type of upload: - +c0.nmu (non maintainer upload) - +c1.sec (security upload) - +c2.su (stable update) Unfortunately +0.nmu sorts before +b1 so I had to put +c0.nmu so that binnmu sort lower. And c could mean change or external change. Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 [EMAIL PROTECTED] GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
Bas Wijnen [EMAIL PROTECTED] writes: Ok, that makes sense. However, with +nmu1, there still is the problem of how to name security uploads. With +s1, they sort after +nmu1, which I think is wrong. There's no reason why we have to stick to one suffix. +s1+nmu1 for an NMU after a security upload is ugly but functional, and the next maintainer release would reset all the suffixes anyway. Likewise with appending another +bN for a binary NMU. As near as I can tell, since you would never base an NMU or security update on a binary NMU, the worst case is +s1+nmu1+b1, which isn't really that horrible. Turning debian into deb and testing into + would make it better 1.7.5+nmu3+deb3.1+.1 is comparable in length to the current 1.7.5+nmu3+lenny1 If you go this route, please make it +deb31, not +deb3.1. The extra dot is historically special and indicates a binNMU. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
[Adding bug #437392 to Cc, which deals with this issue for normal NMUs, because I'm making a suggestion about them.] On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote: devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of debchange --nmu to version an NMU of a native package as X+nmu1 rather than the current X-0.1. Good idea. Even better, IMO, would be to use a system which is in line with non-native packages. How about this rule: - An NMU will add an extra item to the version number, which starts counting at 1. - When a new upstream version of a non-native package is uploaded, the debian revision is set to 0, and the extra item is added to that. This means that non-native NMUs will get the same versions as they always did, while native packages go from 1.8 to 1.8.1, for example. For native packages, it's impossible to package a new upstream version, because there is no upstream. IMO this solution is slightly better than +nmu1, because it makes versions of native and non-native packages more uniformly mangled. However, any solution is better than no solution. :-) Whilst looking at this change, the question arose of what format security uploads of native packages should use, both in general and specifically when debchange's --security option is used. Currently, debchange will produce a version number of X-0.1 in such cases which suffers from the problem described above. It has been suggested that either one of +s1 / +sec1 / +security1 or release1 should be used to avoid the issue. The main difficulty with the latter from the point-of-view of adding support to debchange is that there's no easy way of mapping a changelog distribution (e.g. stable) to a release name, particularly as both stable and oldstable updates may have stable as the last distribution to which the package was uploaded. So the problem is that debchange is unable to know the version should be stable? Or is the problem that versions may collide when oldstable has a security update, and stable needs one as well? That doesn't make sense, because the version will have increased in unstable (by then stable) at the time the oldstable (at that time stable) update was made. I'm a bit confused by the problem. However, I do see a problem with +s1 if +nmu1 is used: +s1 sorts after +nmu1. This means that this versioning can no longer be used if an NMU is needed after a security update. In particular, suppose: - The package version is 1.3 in all distributions. - A security issue is found. - 1.3+s1 is uploaded to stable and testing. - The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable. - Some time passes, and the package is about to migrate to testing. - Migration fails, because 1.3+nmu1 1.3+s1. This problem does not occur if 1.3.1 would be used for the normal NMU (to unstable). After some discussion amongst the team on IRC we decided we'd be happiest following either a request from the security team or a consensus view (or as close to a consensus as -devel ever gets :-). I think using the rules I proposed above for normal NMUs, and +snumber for security NMUs would be best. However, I might misunderstand the problem. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Version numbering for security uploads of native packages
* Adam D. Barratt: Currently, debchange will produce a version number of X-0.1 in such cases which suffers from the problem described above. It has been suggested that either one of +s1 / +sec1 / +security1 or release1 should be used to avoid the issue. For stable and oldstable, we need release1. But the process further down cannot be automated currently, so this doesn't help that much anyway. That's why I'm not inclined to put too much effert into this discussion. 8-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
