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: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Lucas Nussbaum wrote: > […] in my lintian fork […] I got around to releasing Lintian 2.13.0 to unstable earlier today including your suggested changes (so hopefully you can drop your fork for the time being). Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Hi Andreas > My point is simply: As long as the released lintian does not find the > said issue - how can I file a sensible bug report the lintian authors > will consider an issue? I totally welcome if you would file a more > qualified bug report with the insight you have proven in this thread to > make lintian authors understand the problem. The released lintian does report the same details $ lintian -L =classification prottest_3.4.2+dfsg-3.dsc C: prottest source: rules-requires-root-implicitly C: prottest source: debian-build-system debhelper C: prottest source: source-format 3.0 (quilt) $ lintian --version Lintian v2.12.0~bpo9+1 FYI for prottest, you could set the locale detail LC_ALL=C.UTF-8 for the entire debian/rules rather than only for the dh call. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
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: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 16/04/19 at 15:55 +0200, Enrico Weigelt, metux IT consult wrote: > On 13.04.19 10:20, Lucas Nussbaum wrote: > > TL;DR: see https://trends.debian.net and > > https://trends.debian.net/#smells > > > > Hi, > > > > Following this blog post[1] I did some work on setting up a proper > > framework to graph historical trends about Debian packaging practices. > > The result is now available at [2], and I'm confident that I will be > > able to update this on a regular basis (every few months). > > Just a quick idea: > > For packages using git, can you also trace how they're using it ? > > There're several approaches used, some only track debian/ subtree, > some track source tree plus debian/, some w/ extra text-based patches, > some w/ patches already applied in git. I'm outsourcing all the package analysis, which only uses the package's files (source and binary -- only source in my case). What you are suggesting would be super-interesting, but maybe it would be better to plug this into vcswatch -- see https://qa.debian.org/cgi-bin/vcswatch Lucas
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 2019/04/16 21:51, Thomas Goirand wrote: > I'm not sure if I should say thanks, or just hide myself behind the > wall, considering how much work there would be to fix all of these > packages that I need to fix... :/ Heh, that's exactly why these graphs are so great! Rome wasn't built in a day either so I don't think anyone should feel stressed about it, and I think when your packages are team maintained it's a good idea to post to the team list and ask for some help on those fixes. (I'm speaking in the general and not just to you, and I think you're saying that slightly tongue-in-cheek too :) ) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 4/13/19 10:20 AM, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and > https://trends.debian.net/#smells > > Hi, > > Following this blog post[1] I did some work on setting up a proper > framework to graph historical trends about Debian packaging practices. > The result is now available at [2], and I'm confident that I will be > able to update this on a regular basis (every few months). > > Additionally (and much more controversially I guess :-) ) I also added > an analysis of "package smells"[3], such as "not using dh", "not using a > recent debhelper compat level", "not using a 3.0 source format", etc. I > understand that in some cases there might be good reasons to keep those > "smells", but I find it valuable to have them presented in a more > actionable way to fix the cases that should be fixed. So there's a list > of smells, sorted by maintainer/uploader [4]. > > Given that Debian is currently frozen to prepare the buster release, > this is a bad time to start fixing those smells, but I will send a > reminder to debian-devel@ once buster is released. (It's interesting to > see how the number of smells plateaued during previous freezes). > > - Lucas > > [1] https://www.lucas-nussbaum.net/blog/?p=945 > [2] https://trends.debian.net/ > [3] https://trends.debian.net/#smells > [4] https://trends.debian.net/smells-dd-list.txt I'm not sure if I should say thanks, or just hide myself behind the wall, considering how much work there would be to fix all of these packages that I need to fix... :/ Cheers, Thomas Goirand (zigo)
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Tue, Apr 16, 2019 at 01:57:00PM +, Niels Thykier wrote: > > > Similarly > > > > prottest (U) should switch to dh. Current build system: > > debhelper (source version: 3.4.2+dfsg-3) > > python-pyfaidx (U) should switch to dh. Current build system: > > debhelper (source version: 0.5.5.2-1) > > > > are false positives of this lintian fork. > > > > Kind regards > > > > Andreas. > > > > They might be a false-positive, but I am pretty sure this particular bug > is not in Lucas's fork. To my knowledge, that patch simply adds 4 > classification tags that have been posted to the lintian BTS and those > have no conditional logic of their own (they emit tags via existing > branches inside lintian AFAIR). My point is simply: As long as the released lintian does not find the said issue - how can I file a sensible bug report the lintian authors will consider an issue? I totally welcome if you would file a more qualified bug report with the insight you have proven in this thread to make lintian authors understand the problem. Kind regards Andreas. -- http://fam-tille.de
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Andreas Tille: > Hi Niels, > > On Tue, Apr 16, 2019 at 12:54:00PM +, Niels Thykier wrote: >>> speaking about false positives: >>> >>>libhmsbeagle (U) should switch to dh. Current build system: >>> debhelper (source version: 3.1.2+dfsg-5) >>> >>> I have no idea what might have triggered this on the current d/rules >>> file[1]. >>> >>> Kind regards >>> >>>Andreas. >>> >>> [1] https://salsa.debian.org/med-team/libhmsbeagle/blob/master/debian/rules >> >> Try: >> >> lintian -L =classification >> >> And you will probably see something like: >> >> C: source: debian-build-system other >> >> I.e. most likely a false-positive in lintian. Once confirmed, please >> file a bug against lintian or/and provide a MR on salsa for fixing the bug. >> >> For reference, given that trends.d.n relies solely on a lintian (with a >> handful of patches to add a few tags), the issues are most likely in >> lintian or in the particular patches (for the latter, please follow up >> on the relevant bugs filed by Lucas against lintian to add those tags). > > As far as I understood Lucas is talking about a patched lintian and > > grep -R "should switch to dh" /usr/share/lintian/* > > has no results so this warning is not part of lintian. Hi Andreas, While Lucas is talking about a patched lintian, the concrete case is almost certainly a part of "standard" lintian. I remember implementing the tag to detect the "debian build system" and I pretty sure it does *not* cope with "VAR=VALUE dh" calls. You are right that "should switch to dh" does not occur in the lintian codebase. This is because lintian does not assign this value to the missing of a classification tag - this is where Lucas code takes the lintian output and translates the result to "package smells". As a part of this, he basically translates (among other): C: ...: debian-build-system X into ... should switch to dh. Current build system: X (...) When X != 'dh'. > Similarly > > prottest (U) should switch to dh. Current build system: debhelper > (source version: 3.4.2+dfsg-3) > python-pyfaidx (U) should switch to dh. Current build system: debhelper > (source version: 0.5.5.2-1) > > are false positives of this lintian fork. > > Kind regards > > Andreas. > They might be a false-positive, but I am pretty sure this particular bug is not in Lucas's fork. To my knowledge, that patch simply adds 4 classification tags that have been posted to the lintian BTS and those have no conditional logic of their own (they emit tags via existing branches inside lintian AFAIR). Thanks, ~Niels
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 13.04.19 10:20, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and > https://trends.debian.net/#smells > > Hi, > > Following this blog post[1] I did some work on setting up a proper > framework to graph historical trends about Debian packaging practices. > The result is now available at [2], and I'm confident that I will be > able to update this on a regular basis (every few months). Just a quick idea: For packages using git, can you also trace how they're using it ? There're several approaches used, some only track debian/ subtree, some track source tree plus debian/, some w/ extra text-based patches, some w/ patches already applied in git. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Hi Niels, On Tue, Apr 16, 2019 at 12:54:00PM +, Niels Thykier wrote: > > speaking about false positives: > > > >libhmsbeagle (U) should switch to dh. Current build system: > > debhelper (source version: 3.1.2+dfsg-5) > > > > I have no idea what might have triggered this on the current d/rules > > file[1]. > > > > Kind regards > > > >Andreas. > > > > [1] https://salsa.debian.org/med-team/libhmsbeagle/blob/master/debian/rules > > Try: > > lintian -L =classification > > And you will probably see something like: > > C: source: debian-build-system other > > I.e. most likely a false-positive in lintian. Once confirmed, please > file a bug against lintian or/and provide a MR on salsa for fixing the bug. > > For reference, given that trends.d.n relies solely on a lintian (with a > handful of patches to add a few tags), the issues are most likely in > lintian or in the particular patches (for the latter, please follow up > on the relevant bugs filed by Lucas against lintian to add those tags). As far as I understood Lucas is talking about a patched lintian and grep -R "should switch to dh" /usr/share/lintian/* has no results so this warning is not part of lintian. Similarly prottest (U) should switch to dh. Current build system: debhelper (source version: 3.4.2+dfsg-3) python-pyfaidx (U) should switch to dh. Current build system: debhelper (source version: 0.5.5.2-1) are false positives of this lintian fork. Kind regards Andreas. -- http://fam-tille.de
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Andreas Tille: > Hi again, > > speaking about false positives: > >libhmsbeagle (U) should switch to dh. Current build system: > debhelper (source version: 3.1.2+dfsg-5) > > I have no idea what might have triggered this on the current d/rules > file[1]. > > Kind regards > >Andreas. > > [1] https://salsa.debian.org/med-team/libhmsbeagle/blob/master/debian/rules > Try: lintian -L =classification And you will probably see something like: C: source: debian-build-system other I.e. most likely a false-positive in lintian. Once confirmed, please file a bug against lintian or/and provide a MR on salsa for fixing the bug. For reference, given that trends.d.n relies solely on a lintian (with a handful of patches to add a few tags), the issues are most likely in lintian or in the particular patches (for the latter, please follow up on the relevant bugs filed by Lucas against lintian to add those tags). Thanks, ~Niels
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Hi again, speaking about false positives: libhmsbeagle (U) should switch to dh. Current build system: debhelper (source version: 3.1.2+dfsg-5) I have no idea what might have triggered this on the current d/rules file[1]. Kind regards Andreas. [1] https://salsa.debian.org/med-team/libhmsbeagle/blob/master/debian/rules -- http://fam-tille.de
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Lucas Nussbaum: > On 16/04/19 at 08:52 +0200, Andreas Tille wrote: >> On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote: >>> On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: biococoa (U) does not use Debhelper (no compat level found) (source version: 2.2.2-4) biococoa (U) should switch to dh. Current build system: cdbs (source version: 2.2.2-4) >>> >>> | % grep cdbs -r biococoa-2.2.2 >>> | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk >>> | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk >>> | biococoa-2.2.2/debian/control:Build-Depends: cdbs, >>> | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's >>> a cdbs issue) >>> | biococoa-2.2.2/debian/changelog: * debian/control (Build-Depends): Add >>> cdbs and quilt. Drop gnustep-make >> >> This explains the cdbs smelling (and I loved to get rid of this but >> this needs to be fixed by gnustep.mk). But in how far is >> >> "no compat level found" >> >> sensible? > > That's because, once lintian sees that the package does not use debhelper > or cdbs, it returns from debhelper.pm and thus doesn't reach the point > where the tag for debhelper-compat-level (which is an addition in my > lintian fork) is emitted. > > L. > Here "cdbs" being "a part of cdbs known to use debhelper". At the moment, these cdbs snippets are (to lintian) known to use debhelper: * /usr/share/cdbs/1/rules/debhelper.mk * /usr/share/R/debian/r-cran.mk Patches/MR are welcome at https://salsa.debian.org/lintian/lintian/ or in the BTS. At the moment, the code you are looking for will be: https://salsa.debian.org/lintian/lintian/blob/master/checks/debhelper.pm#L180 Thanks, ~Niels
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 16/04/19 at 08:52 +0200, Andreas Tille wrote: > On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote: > > On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: > > > biococoa (U) does not use Debhelper (no compat level found) > > > (source version: 2.2.2-4) > > > biococoa (U) should switch to dh. Current build system: cdbs > > > (source version: 2.2.2-4) > > > > | % grep cdbs -r biococoa-2.2.2 > > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk > > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk > > | biococoa-2.2.2/debian/control:Build-Depends: cdbs, > > | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's > > a cdbs issue) > > | biococoa-2.2.2/debian/changelog: * debian/control (Build-Depends): Add > > cdbs and quilt. Drop gnustep-make > > This explains the cdbs smelling (and I loved to get rid of this but > this needs to be fixed by gnustep.mk). But in how far is > > "no compat level found" > > sensible? That's because, once lintian sees that the package does not use debhelper or cdbs, it returns from debhelper.pm and thus doesn't reach the point where the tag for debhelper-compat-level (which is an addition in my lintian fork) is emitted. L.
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote: > On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: > > biococoa (U) does not use Debhelper (no compat level found) > > (source version: 2.2.2-4) > > biococoa (U) should switch to dh. Current build system: cdbs > > (source version: 2.2.2-4) > > | % grep cdbs -r biococoa-2.2.2 > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk > | biococoa-2.2.2/debian/control:Build-Depends: cdbs, > | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's a > cdbs issue) > | biococoa-2.2.2/debian/changelog: * debian/control (Build-Depends): Add > cdbs and quilt. Drop gnustep-make This explains the cdbs smelling (and I loved to get rid of this but this needs to be fixed by gnustep.mk). But in how far is "no compat level found" sensible? Kind regards Andreas. -- http://fam-tille.de
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: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 15/04/19 at 16:55 +0200, Andreas Tille wrote: > Are you sure that you are not tricked by false positives from lintian? I might be, but if lintian reports something incorrectly about your package, it's probably worth fixing in lintian. Lucas
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: > biococoa (U) does not use Debhelper (no compat level found) > (source version: 2.2.2-4) > biococoa (U) should switch to dh. Current build system: cdbs > (source version: 2.2.2-4) | % grep cdbs -r biococoa-2.2.2 | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk | biococoa-2.2.2/debian/control:Build-Depends: cdbs, | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's a cdbs issue) | biococoa-2.2.2/debian/changelog: * debian/control (Build-Depends): Add cdbs and quilt. Drop gnustep-make Regards, Bastian -- Military secrets are the most fleeting of all. -- Spock, "The Enterprise Incident", stardate 5027.4
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Sat, Apr 13, 2019 at 03:46:57PM +0200, gregor herrmann wrote: > On Sat, 13 Apr 2019 10:20:53 +0200, Lucas Nussbaum wrote: > > > TL;DR: see https://trends.debian.net and > > https://trends.debian.net/#smells > > Very nice, thank you. +1 I like it a lot! > > [4] https://trends.debian.net/smells-dd-list.txt As far as I understood you are using lintian results. However, the real packaging does not (always) reflect this. At least I've found an example. Link [4] lists: biococoa (U) does not use Debhelper (no compat level found) (source version: 2.2.2-4) biococoa (U) should switch to dh. Current build system: cdbs (source version: 2.2.2-4) However: $ apt-get source biococoa $ cd biococoa-2.2.2/ $ cat debian/compat 10 $ grep debhelper debian/control debhelper (>= 11~), Are you sure that you are not tricked by false positives from lintian? Kind regards and thanks a lot for this great effort. Andreas. -- http://fam-tille.de
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Apr 13, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and Nice. I suggest to add a graph detailing: - packages with at least one init script - packages with at least one systemd unit - packages with at least one init script and one systemd unit Also, did I miss the memo about traditional debhelper being superseded by dh? Why should I switch? -- ciao, Marco signature.asc Description: PGP signature
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Sat, 13 Apr 2019 10:20:53 +0200, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and > https://trends.debian.net/#smells Very nice, thank you. > [4] https://trends.debian.net/smells-dd-list.txt This list is slightly unhelpful (for my case / the Debian Perl Group) as it reports hundreds [0] of "git repository still hosted on alioth" warnings which are not factually true. (I know, the Vcs-* fields in the packages in the archive still point to alioth for all the not-yet-uploaded packages but the repos are already moved …) Cheers, gregor [0] for the perl team: 2266 -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Leonard Cohen: Suzanne signature.asc Description: Digital Signature
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
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Sat, Apr 13, 2019 at 10:20:53AM +0200, Lucas Nussbaum wrote: > https://trends.debian.net/#smells there are two minor issues with the smells *graph*: not using salsa should only be graphed since salsa exists (and not since 2005), same for compat < 9. -- 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: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Sat, Apr 13, 2019 at 4:21 PM Lucas Nussbaum wrote: > > TL;DR: see https://trends.debian.net and > https://trends.debian.net/#smells > These graphs look ambiguous... Shouldn't the x-axis be year? -- Shengjing Zhu
native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Sat, Apr 13, 2019 at 11:42:38AM +0200, Lucas Nussbaum wrote: > Well you could switch to 3.0 (native). I see no point whatsoever in 3.0 (native). IMO 3.0 (quilt) is sensible and 1.0 too, whether native or not. *If* native package in todays world are still sensible... > > But you don't consider native packages as smelly, which I think you maybe > > should. > I'm not sure we have ever had a real discussion about that. But yes that > might be true. It would make it easier to expose changes in derivatives. I also see no benefit of native packages. None. I've just not done the change for src:piuparts as change is hard :) Maybe I forgot some argument in favor of native packages, if so, I'd be glad to be reminded. (Except change is hard, which isn't a good argument forever.) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 13/04/19 at 09:28 +, Holger Levsen wrote: > Hi Lucas, > > On Sat, Apr 13, 2019 at 10:20:53AM +0200, Lucas Nussbaum wrote: > > TL;DR: see https://trends.debian.net and > > https://trends.debian.net/#smells > > that's beautiful! thank you! > > > [4] https://trends.debian.net/smells-dd-list.txt > > for me there are two smelly packages, src:tuxtype should use source 3.0 > indeed, but for src:piuparts I really don't see why. Though I would > quite probably agree that src:piuparts should not be native, and then > 3.0 would make more sense. Well you could switch to 3.0 (native). Are there good reasons to stay with 1.0 for a native package ? Even if I agree that there's probably not much to gain, there's also even less to lose. > But you don't consider native packages as smelly, which I think you maybe > should. I'm not sure we have ever had a real discussion about that. But yes that might be true. It would make it easier to expose changes in derivatives. Lucas signature.asc Description: PGP signature
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Hi Lucas, On Sat, Apr 13, 2019 at 10:20:53AM +0200, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and > https://trends.debian.net/#smells that's beautiful! thank you! > [4] https://trends.debian.net/smells-dd-list.txt for me there are two smelly packages, src:tuxtype should use source 3.0 indeed, but for src:piuparts I really don't see why. Though I would quite probably agree that src:piuparts should not be native, and then 3.0 would make more sense. But you don't consider native packages as smelly, which I think you maybe should. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 4/13/19 10:20 AM, Lucas Nussbaum wrote: > Additionally (and much more controversially I guess :-) ) I also added > an analysis of "package smells"[3], such as "not using dh", "not using a > recent debhelper compat level", "not using a 3.0 source format", etc. I > understand that in some cases there might be good reasons to keep those > "smells", but I find it valuable to have them presented in a more > actionable way to fix the cases that should be fixed. So there's a list > of smells, sorted by maintainer/uploader [4]. You should check if those issues present in unstable are not already fixed in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
TL;DR: see https://trends.debian.net and https://trends.debian.net/#smells Hi, Following this blog post[1] I did some work on setting up a proper framework to graph historical trends about Debian packaging practices. The result is now available at [2], and I'm confident that I will be able to update this on a regular basis (every few months). Additionally (and much more controversially I guess :-) ) I also added an analysis of "package smells"[3], such as "not using dh", "not using a recent debhelper compat level", "not using a 3.0 source format", etc. I understand that in some cases there might be good reasons to keep those "smells", but I find it valuable to have them presented in a more actionable way to fix the cases that should be fixed. So there's a list of smells, sorted by maintainer/uploader [4]. Given that Debian is currently frozen to prepare the buster release, this is a bad time to start fixing those smells, but I will send a reminder to debian-devel@ once buster is released. (It's interesting to see how the number of smells plateaued during previous freezes). - Lucas [1] https://www.lucas-nussbaum.net/blog/?p=945 [2] https://trends.debian.net/ [3] https://trends.debian.net/#smells [4] https://trends.debian.net/smells-dd-list.txt signature.asc Description: PGP signature
