Your message dated Sun, 07 Apr 2024 05:34:03 +
with message-id
and subject line Bug#970234: fixed in debian-policy 4.7.0.0
has caused the Debian Bug report #970234,
regarding consider dropping "No hard links in source packages"
to be marked as done.
This means that you claim that t
cy 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 ti
; > 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.
>
raint.
>
> 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
This patch is still waiting for one more second. It was previously
seconded by Helmut.
Russ Allbery 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'
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
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages
>
> It&#x
Russ Allbery 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 packag
>>>>> "Russ" == Russ Allbery writes:
Russ> Sam Hartman 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 spac
Helmut Grohne 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.
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.
On Tue, Oct 13, 2020 at 09:44:42AM -0400, Sam Hartman wrote:
> > "Giacomo" == Giacomo Catenazzi 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 /u
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.
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 w
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
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/w
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
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
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
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
On Wed, May 14, 2003 at 06:22:27AM -0700, Pedro Salgueiro wrote:
> Hi.
> What is the best way to create hard links?
> Having the links already created in the package or
> create them in the postinst?
You should probably ask the debian-mentors@lists.debian.org mailing
list. Both ar
Hi.
What is the best way to create hard links?
Having the links already created in the package or
create them in the postinst?
Thanks.
Pedro Salgueiro
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Joey Hess <[EMAIL PROTECTED]> on Thu, Mar 26, 1998 at 12:37:48PM -0800:
> hard links, this is not an issue. This makes hard links more robust and a
> better choice for certian situations. This is why they continue to exist,
> and have not been replaced entirely by symlinks allrea
On Thu, 26 Mar 1998, Topi Miettinen wrote:
> - It's hard to notice hard links, they look exactly like normal files
> (AFAIK, there are no tools exept ls -li and find -inum). Many programs
> support symbolic links, including web/ftp servers.
[EMAIL PROTECTED]:/home/kooij> $ ls -l
Topi Miettinen <[EMAIL PROTECTED]> writes:
> Locating hard links with only ls -li or find -inum is inhuman task,
> whereas any graphical file browser can easily show symlinks with
> different icon, for example (I don't use them, so I don't know
> whether they actually
hier uses.
Topi> Then there is consistency issue. Package X uses symlinks but
Topi> package Y hard links. Why can't they use the same?
Because there is more than one way to do it? ;-). Frankly, I
would trust the maintainers to decide which flavour of the link to
use.
Topi Miettinen wrote:
> Some packages use hard links to provide different names for single
> executable. I think this practice is at least questionable:
>
> - It's hard to notice hard links, they look exactly like normal files
> (AFAIK, there are no tools exept ls -li a
26 matches
Mail list logo
