Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#970234: consider dropping "No hard links in source packages"
1 view
Skip to first unread message
Helmut Grohne
Sep 13, 2020, 7:00:03 AM9/13/20
to
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.
Helmut
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.
Helmut
Giacomo Catenazzi
Oct 12, 2020, 10:30:03 AM10/12/20
to
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]
Giacomo Catenazzi
Oct 12, 2020, 11:10:03 AM10/12/20
to
On 12.10.2020 16:22, Andrey Rahmatullin wrote:
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
> 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?
>> Now we are more strict on where we can split filesystems
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
Andrey Rahmatullin
Oct 12, 2020, 11:20:03 AM10/12/20
to
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
> > > 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
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
--
WBR, wRAR
Helmut Grohne
Oct 12, 2020, 3:00:03 PM10/12/20
to
Hi cate,
On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote:
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
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
> 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).
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.
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
Giacomo Catenazzi
Oct 13, 2020, 8:40:04 AM10/13/20
to
Hello Helmut
On 12.10.2020 19:30, Helmut Grohne wrote:
> 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.
Your are totally right. And it is also on the subject line.
So: I have not reasonable explanation.
ciao
cate
On 12.10.2020 19:30, Helmut Grohne wrote:
> 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.
So: I have not reasonable explanation.
ciao
cate
Sam Hartman
Oct 13, 2020, 10:00:02 AM10/13/20
to
>>>>> "Giacomo" == Giacomo Catenazzi <ca...@debian.org> writes:
Giacomo> The rationale was probably similar so symlinks: they may
Giacomo> fail across different filesystems, and we supported to have
Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
Giacomo> /home /tmp /boot etc on different file systems. Now we are
Giacomo> more strict on where we can split filesystems (and disk are
Giacomo> larger, and LVM simplified much of filesystem handling).
But I think even in 1996, we anticipated a single source package
(*source package*) being unpacked on a single filesystem.
Perhaps we were worried about filesystems like umsdos?
I think that hard links in a source package are fine provided that
breaking the hard links would not either break the build or provide an
unreasonable space multiplier.
Giacomo> The rationale was probably similar so symlinks: they may
Giacomo> fail across different filesystems, and we supported to have
Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
Giacomo> /home /tmp /boot etc on different file systems. Now we are
Giacomo> more strict on where we can split filesystems (and disk are
Giacomo> larger, and LVM simplified much of filesystem handling).
But I think even in 1996, we anticipated a single source package
(*source package*) being unpacked on a single filesystem.
Perhaps we were worried about filesystems like umsdos?
I think that hard links in a source package are fine provided that
breaking the hard links would not either break the build or provide an
unreasonable space multiplier.
Bill Allombert
Oct 13, 2020, 10:30:03 AM10/13/20
to
On Tue, Oct 13, 2020 at 09:44:42AM -0400, Sam Hartman wrote:
> >>>>> "Giacomo" == Giacomo Catenazzi <ca...@debian.org> writes:
>
> Giacomo> The rationale was probably similar so symlinks: they may
> Giacomo> fail across different filesystems, and we supported to have
> Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
> Giacomo> /home /tmp /boot etc on different file systems. Now we are
> Giacomo> more strict on where we can split filesystems (and disk are
> Giacomo> larger, and LVM simplified much of filesystem handling).
>
> But I think even in 1996, we anticipated a single source package
> (*source package*) being unpacked on a single filesystem.
> Perhaps we were worried about filesystems like umsdos?
It is good to see I am not the only one left who remember about umsdos!
> >>>>> "Giacomo" == Giacomo Catenazzi <ca...@debian.org> writes:
>
> Giacomo> The rationale was probably similar so symlinks: they may
> Giacomo> fail across different filesystems, and we supported to have
> Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
> Giacomo> /home /tmp /boot etc on different file systems. Now we are
> Giacomo> more strict on where we can split filesystems (and disk are
> Giacomo> larger, and LVM simplified much of filesystem handling).
>
> But I think even in 1996, we anticipated a single source package
> (*source package*) being unpacked on a single filesystem.
> Perhaps we were worried about filesystems like umsdos?
I am pretty sure we were concerned about source packages being
unpackable on non Debian systems, though.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Sam Hartman
Oct 13, 2020, 11:40:02 AM10/13/20
to
>>>>> "Bill" == Bill Allombert <ball...@debian.org> writes:
Bill> I am pretty sure we were concerned about source packages being
Bill> unpackable on non Debian systems, though.
And I think we probably still are. I was trying to capture the concerns
there in the part of my message you trimmed.
My rationale is that I don't think we want to work around an upstream
build system or repack sources just because it has hard links. On the
other hand I also don't think we want to depend on hard links being
preserved.
Bill> I am pretty sure we were concerned about source packages being
Bill> unpackable on non Debian systems, though.
And I think we probably still are. I was trying to capture the concerns
there in the part of my message you trimmed.
My rationale is that I don't think we want to work around an upstream
build system or repack sources just because it has hard links. On the
other hand I also don't think we want to depend on hard links being
preserved.
Russ Allbery
Sep 20, 2022, 11:00:02 PM9/20/22
to
Helmut Grohne <hel...@subdivi.de> writes:
> 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.
I'm inclined to agree with you on this, but it's probably worth mentioning
> 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.
somewhere in this bug that the AFS file system is still used and still, so
far as I know, does not support cross-directory hard links because of its
per-directory ACL system. I'm not sure what tar does in this situation:
whether it fails or whether it just silently duplicates the file.
I'm not sure that we care, but that sort of concern (along with a general
dislike of hard links) is probably the original rationale.
The fact that this has gone unnoticed in a source package in an existing
release makes a pretty strong argument that nothing in Debian cares and we
should just remove the constraint.
Sam Hartman <hart...@debian.org> writes:
> I think that hard links in a source package are fine provided that
> breaking the hard links would not either break the build or provide an
> unreasonable space multiplier.
likely and important enough to have it be worth retaining a section
talking about this, as opposed to using the "not every bug is a Policy
violation" rule? We do pay a (small) complexity cost for each additional
requirement we put in Policy, so I'm tempted to just drop this entirely
and bank the complexity reduction.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sam Hartman
Sep 21, 2022, 9:40:03 AM9/21/22
to
>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
Russ> Sam Hartman <hart...@debian.org> writes:
>> I think that hard links in a source package are fine provided
>> that breaking the hard links would not either break the build or
>> provide an unreasonable space multiplier.
Russ> I agree with you that those would be undesirable properties,
Russ> but are they likely and important enough to have it be worth
Russ> retaining a section talking about this, as opposed to using
Russ> the "not every bug is a Policy violation" rule? We do pay a
Russ> (small) complexity cost for each additional requirement we put
Russ> in Policy, so I'm tempted to just drop this entirely and bank
Russ> the complexity reduction.
You have me sold on not likely enough to matter.
I do think that having the build break (or worse produce bad results) on
hard link breaking would be a really important problem because of how
much it violates the principle of least surprise, but I agree that it is
unlikely enough that it need not be covered in policy.
--Sam
Russ> Sam Hartman <hart...@debian.org> writes:
>> I think that hard links in a source package are fine provided
>> that breaking the hard links would not either break the build or
>> provide an unreasonable space multiplier.
Russ> but are they likely and important enough to have it be worth
Russ> retaining a section talking about this, as opposed to using
Russ> the "not every bug is a Policy violation" rule? We do pay a
Russ> (small) complexity cost for each additional requirement we put
Russ> in Policy, so I'm tempted to just drop this entirely and bank
Russ> the complexity reduction.
You have me sold on not likely enough to matter.
I do think that having the build break (or worse produce bad results) on
hard link breaking would be a really important problem because of how
much it violates the principle of least surprise, but I agree that it is
unlikely enough that it need not be covered in policy.
--Sam
Russ Allbery
Sep 22, 2022, 10:30:03 PM9/22/22
to
Russ Allbery <r...@debian.org> writes:
> The fact that this has gone unnoticed in a source package in an existing
> release makes a pretty strong argument that nothing in Debian cares and
> we should just remove the constraint.
Here is a patch dropping the restriction on hard links in source packages
> The fact that this has gone unnoticed in a source package in an existing
> release makes a pretty strong argument that nothing in Debian cares and
> we should just remove the constraint.
that I think is ready for seconds. I'm copying Guillem for his review, in
case there's some dpkg concern.
Helmut Grohne
Sep 23, 2022, 1:20:03 AM9/23/22
to
Hi Russ,
On Thu, Sep 22, 2022 at 07:20:00PM -0700, Russ Allbery wrote:
> From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery <r...@debian.org>
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages
>
> It's not clear why this restriction was in place, and Debian
> included a package containing hard links without anyone noticing
> in the last release.
> ---
> policy/ch-source.rst | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index c7415fc..a7df539 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably possible. [#]_
> Restrictions on objects in source packages
> ------------------------------------------
>
> -The source package must not contain any hard links, [#]_ device special
> -files, sockets or setuid or setgid files.. [#]_
> +The source package must not contain device special files, sockets, or
> +setuid or setgid files. [#]_
>
> .. _s-debianrules:
>
> @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for any ``foo``.
> would be nice if the modification time of the upstream source would
> be preserved.
>
> -.. [#]
> - This is not currently detected when building source packages, but
> - only when extracting them.
> -
> - Hard links may be permitted at some point in the future, but would
> - require a fair amount of work.
> -
> .. [#]
> Setgid directories are allowed.
>
Seconded.
Helmut
On Thu, Sep 22, 2022 at 07:20:00PM -0700, Russ Allbery wrote:
> From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery <r...@debian.org>
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages
>
> It's not clear why this restriction was in place, and Debian
> included a package containing hard links without anyone noticing
> in the last release.
> ---
> policy/ch-source.rst | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index c7415fc..a7df539 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably possible. [#]_
> Restrictions on objects in source packages
> ------------------------------------------
>
> -The source package must not contain any hard links, [#]_ device special
> -files, sockets or setuid or setgid files.. [#]_
> +The source package must not contain device special files, sockets, or
> +setuid or setgid files. [#]_
>
> .. _s-debianrules:
>
> @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for any ``foo``.
> would be nice if the modification time of the upstream source would
> be preserved.
>
> -.. [#]
> - This is not currently detected when building source packages, but
> - only when extracting them.
> -
> - Hard links may be permitted at some point in the future, but would
> - require a fair amount of work.
> -
> .. [#]
> Setgid directories are allowed.
>
Seconded.
Helmut
Russ Allbery
Sep 10, 2023, 1:50:03 PM9/10/23
to
This patch is still waiting for one more second. It was previously
seconded by Helmut.
Russ Allbery <r...@debian.org> writes:
> Here is a patch dropping the restriction on hard links in source
> packages that I think is ready for seconds. I'm copying Guillem for his
> review, in case there's some dpkg concern.
seconded by Helmut.
Russ Allbery <r...@debian.org> writes:
> Here is a patch dropping the restriction on hard links in source
> packages that I think is ready for seconds. I'm copying Guillem for his
> review, in case there's some dpkg concern.
Edward Little
Sep 10, 2023, 9:10:03 PM9/10/23
to
Please remove the following email address: e.lit...@gmail.com
Guillem Jover
Sep 10, 2023, 9:10:03 PM9/10/23
to
Hi!
On Thu, 2022-09-22 at 19:20:00 -0700, Russ Allbery wrote:
> Russ Allbery <r...@debian.org> writes:
> > The fact that this has gone unnoticed in a source package in an existing
> > release makes a pretty strong argument that nothing in Debian cares and
> > we should just remove the constraint.
>
> Here is a patch dropping the restriction on hard links in source packages
> that I think is ready for seconds. I'm copying Guillem for his review, in
> case there's some dpkg concern.
I'm not really sure what the footnote really refers to, TBH, as I'm
not aware of any such check, or what would require a fair amount of
work. Besides the other potential issues mentioned on the bug, which
I agree we might not care much about, a case that comes to mind would
be that patching hard linked source files can end up being very
confusing, and might not really break the build but can end up not
producing what one might expect. I've quickly prepared the attached
tentative and completely untested patch, to add a warning in that case,
which I guess I might be targeting for dpkg 1.22.1 (once I've added
some tests).
But given that hard links in source packages do not seem prevalent
at all, and that the tooling or linters can be improved in that
direction I suppose it might make sense to lift this specific
restriction.
> >From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery <r...@debian.org>
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages
Seconded.
Thanks,
Guillem
On Thu, 2022-09-22 at 19:20:00 -0700, Russ Allbery wrote:
> Russ Allbery <r...@debian.org> writes:
> > The fact that this has gone unnoticed in a source package in an existing
> > release makes a pretty strong argument that nothing in Debian cares and
> > we should just remove the constraint.
>
> Here is a patch dropping the restriction on hard links in source packages
> that I think is ready for seconds. I'm copying Guillem for his review, in
> case there's some dpkg concern.
not aware of any such check, or what would require a fair amount of
work. Besides the other potential issues mentioned on the bug, which
I agree we might not care much about, a case that comes to mind would
be that patching hard linked source files can end up being very
confusing, and might not really break the build but can end up not
producing what one might expect. I've quickly prepared the attached
tentative and completely untested patch, to add a warning in that case,
which I guess I might be targeting for dpkg 1.22.1 (once I've added
some tests).
But given that hard links in source packages do not seem prevalent
at all, and that the tooling or linters can be improved in that
direction I suppose it might make sense to lift this specific
restriction.
> >From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery <r...@debian.org>
> Date: Thu, 22 Sep 2022 19:15:52 -0700
Thanks,
Guillem
Russ Allbery
Sep 10, 2023, 11:30:04 PM9/10/23
to
Guillem Jover <gui...@debian.org> writes:
> I'm not really sure what the footnote really refers to, TBH, as I'm not
> aware of any such check, or what would require a fair amount of
> work.
Yeah, it seems to be a mystery to everyone. There is an explicit entry in
> I'm not really sure what the footnote really refers to, TBH, as I'm not
> aware of any such check, or what would require a fair amount of
> work.
the debian/changelog of Policy from Ian Jackson about it for version
2.1.1, but all it says is:
* Hard links are forbidden in source packages (they didn't work anyway,
and can't easily be made to work reliably).
This is from when Ian was maintaining dpkg, so presumably he thought
something was broken at the time, but it seems to have been lost in
history. They do obviously work now.
> Besides the other potential issues mentioned on the bug, which I agree
> we might not care much about, a case that comes to mind would be that
> patching hard linked source files can end up being very confusing, and
> might not really break the build but can end up not producing what one
> might expect. I've quickly prepared the attached tentative and
> completely untested patch, to add a warning in that case, which I guess
> I might be targeting for dpkg 1.22.1 (once I've added some tests).
> But given that hard links in source packages do not seem prevalent at
> all, and that the tooling or linters can be improved in that direction I
> suppose it might make sense to lift this specific restriction.
0 new messages