Bug#970234: consider dropping "No hard links in source packages"
Hi cate, On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote: > The rationale was probably similar so symlinks: they may fail across > different filesystems, and we supported to have e.g. / /usr /usr/share > /usr/local /var (and various /var/*) /home /tmp /boot etc on different file > systems. Now we are more strict on where we can split filesystems (and disk > are larger, and LVM simplified much of filesystem handling). You appear to be talking about binary packages. This bug is about source packages. When you unpack a source package, you are creating a directory hiearchy rooted at the point where you start unpacking. There is not possibly any reasonable way to split your source package into multiple file systems. This is very different from binary packages where the underlying hiearchy is shared with other packages and directories frequently already exist. > I think a hardlink on same directory should be fine, or within directories > which must be on the same filesystem. I argue that all files within a source package are always located on the same filesystem, because the unpack step creates the source package root directory on one file system and everything else resides on that very filesystem. For binary packages, restricting the use of symlinks makes a lot more sense to me. Helmut
Bug#970234: consider dropping "No hard links in source packages"
On Mon, Oct 12, 2020 at 05:05:43PM +0200, Giacomo Catenazzi wrote: > > > Now we are more strict on where we can split filesystems > > What do you mean? > > If I remember correctly, now we do not support / and /usr to be on a > different filesystems Not really, please read https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ -- WBR, wRAR signature.asc Description: PGP signature
Bug#970234: consider dropping "No hard links in source packages"
On 12.10.2020 16:22, Andrey Rahmatullin wrote: On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote: Now we are more strict on where we can split filesystems What do you mean? If I remember correctly, now we do not support / and /usr to be on a different filesystems, and I think there were few other corner cases which were forbidden. ciao cate
Bug#970234: consider dropping "No hard links in source packages"
On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote: > Now we are more strict on where we can split filesystems What do you mean? -- WBR, wRAR signature.asc Description: PGP signature
Bug#970234: consider dropping "No hard links in source packages"
On 13.09.2020 12:52, Helmut Grohne wrote: Package: debian-policy Version: 4.5.0.3 Severity: wishlist Jakub stumbled into the "No hard links in source packages" requirement added around 1996 and couldn't make sense of it. Neither could Christoph nor myself. tar does support hard links just fine. lintian does not check this property. sugar-log-activity/38 is an example package violating the property. It is shipped in buster and technically rc-buggy though no bug is filed about it. I believe that the requriement needs a rationale. Failing that, it should be dropped. The rationale was probably similar so symlinks: they may fail across different filesystems, and we supported to have e.g. / /usr /usr/share /usr/local /var (and various /var/*) /home /tmp /boot etc on different file systems. Now we are more strict on where we can split filesystems (and disk are larger, and LVM simplified much of filesystem handling). I think a hardlink on same directory should be fine, or within directories which must be on the same filesystem. ciao cate [for symlinks we have the problem with relative links (containing "../") passing filesystem boundaries]
Bug#971977: debian-policy: debian/changelog date syntax description inconsistent/ambiguous wrt. to day of month
Hi Guillem, thanks for your prompt concurrence with both, #971977 and #971975. One nitpick: Guillem Jover wrote: > Right. I've clarified this now locally for deb-changelog(5) as follows: > +Is a one- or two-digit day of the month (B<01>-B<31>), where the heading ^^^ > +zero is optional, but conventionally does not get omitted. [...] >Any line that consists entirely (i.e., no leading whitespace) of B<#> ^^^ >or B style comments or RCS keywords. You once use "heading" and once "leading". Is this on purpose? At least for "whitespace" the term "leading whitespace" seems to be the common one, so I'm not sure if "heading zero" is really a proper term. (But then again, English is not my mother tongue and I might be wrong here.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
