Bug#964421: ITP: debmutate -- Python modules to modify Debian packages
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: debmutate Version : 0.1 Upstream Author : Jelmer Vernooij * URL : https://salsa.debian.org/jelmer/debmutate * License : GPL Programming Lang: Python Description : Format-preserving manipulation of Debian control files in Python Debmutate is a set of Python modules for manipulating the control files of Debian packages, with the ability to preserve the existing formatting of the control files. The package is built on top of python-debian, and split out from the lintian-brush source code.
Re: https://trends.debian.net/ - is this 20000 source packages since 2006?
Hi, Quoting Steffen Möller (2020-07-04 13:24:36) > I just skimmed through https://trends.debian.net/ and am impressed. Many > thanks for these figures. same from me! :) > Do you accept wishes for additional graphs? Mine would be on the number of > build dependencies as a scale for software complexity and how this evolved > over time. My hunch is that later software has more dependencies than earlier > ones. Would of course be cool to also have other software metrics over time. > Anyway - fanstastic plots already! This is very hard to measure. How do you count A|B dependencies? How do you count dependencies only on architecture X? How do you count dependencies on virtual packages for which there are several providers, each pulling a different set of packages in? Also, we are probably not just interested in the direct dependencies but also in indirect dependencies, so it's not only the build dependencies we have to look at but also the runtime dependencies. Do Recommends count? One possible metric would be to compute the lower bound (strong dependencies) as well as the upper bound (dependency closure) for each source package using dose-ceve. Still, I wonder how useful it is to know the resulting number. Some ecosystems prefer many small packages while others have only few big packages. A related graph that you might find interesting is this one: https://bootstrap.debian.net/history.html This is the minimal set of packages necessary to build all other packages, assuming native compilation and without build profiles. As you can see, the number increases over time, suggesting that packages indeed add more and more build dependencies as well as runtime dependencies. > What is right in the open but I do not see discussed in this context is the > sheer amount of packages that are added to the distribution. It is a raise > from close to 1 to similarly close to 3 in a bit over 14 years, so > this makes close to 1500 packages/anno or close to 4 per day, equally > throughout all these years. I don't know if it makes a big difference, but this is probably not accounting for the packages that are getting removed per year? > Knowing about all the time I spend on checking copyrights already, not always > successfully, I know about the enormous work our FTPmasters invest into > keeping this up. So, many thanks! Thank you!! :) cheers, josch signature.asc Description: signature
Re: https://trends.debian.net/ - is this 20000 source packages since 2006?
On 7/6/20 8:04 AM, Lucas Nussbaum wrote: > Hi, > > On 04/07/20 at 13:24 +0200, Steffen Möller wrote: >> Hello, >> >> I just skimmed through https://trends.debian.net/ and am impressed. Many >> thanks for these figures. > > Thanks > >> Do you accept wishes for additional graphs? > > Sure > >> Mine would be on the number of build dependencies as a scale for >> software complexity and how this evolved over time. My hunch is that >> later software has more dependencies than earlier ones. Would of course >> be cool to also have other software metrics over time. Anyway - >> fanstastic plots already! > > I use lintian as the source of data. So basically you need to get the > information you want in a lintian classification tag, and then I take > care of adding the graphs :) > > For your above example, do you mean "direct build-deps listed in > debian/control", or "transitive build-deps" ? The latter would require a > lot more analysis. is the complexity really defined by the number of build deps? What about the height of the build stack for a package? Like determining the dependency levels in ben, but that for every package. Matthias
Re: https://trends.debian.net/ - is this 20000 source packages since 2006?
On Sat, Jul 04, 2020 at 01:24:36PM +0200, Steffen Möller wrote: > What is right in the open but I do not see discussed in this context is > the sheer amount of packages that are added to the distribution. It is a > raise from close to 1 to similarly close to 3 in a bit over 14 > years, so this makes close to 1500 packages/anno or close to 4 per day, I guess it's not being discussed because it's no news?! Even wikipedia knows about it, see the table of the bottom of https://en.wikipedia.org/wiki/Debian_version_history Granted, those are only binary packages but... https://tests.reproducible-builds.org/debian/unstable/amd64/stats_pkg_state.png OTOH shows the growth of the number of sources packages in the last 6 years and matches the above. And then there was a talk by a DPL with the first name "Lucas" at FOSDEM a few years ago, where he spoke about having 40 packages in Debian one day... I don't remember whether he ment source or binary packages though :) > equally throughout all these years. Knowing about all the time I spend > on checking copyrights already, not always successfully, I know about > the enormous work our FTPmasters invest into keeping this up. So, many > thanks! yes, very amazing work of everyone involved! -- cheers, 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: Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems
On Sun, Jul 05, 2020 at 06:17:47PM -0300, Henrique de Moraes Holschuh wrote: Hi, > It depends. Are the CLIs involved compatible? Yes and no. :) If you just rely on `mkfs.exfat /dev/sdX` yes, if you want to use some special options they are not. Sven
