Thanks for the responses!
I understand the reasoning now and it does make sense. I'm probably just
running into these issues as a corner case because I'm hosting every
part of my repository chain on the same box during initial development
and setup and so I'm running into odd things (like rebuilding sources on
a "production" machine). And it's not like this cause a big issue
really...the "problem" was found and resolved the same afternoon I first
set it up. Can't really complain too much about that.
I guess in an ideal world I would have different names for these
protocols. Say the current functionality of `copy` would be `file` (or
actually I guess `copy-file` maybe?) and the current functionality of
`file` would be something like `symlink` juts to make it clear.
I think changing the default is probably crazy, but honestly I think
adding an option might even be a little too much. Too many options can
be tiresome as well and the functionality is there after all.
Regardless thanks so much for developing/maintaining
apt/reprepro/everything else. Even considering this minor hiccup,
setting up and using this as a hosting/deployment tool is really great.
Thanks for all the great work!
Cheers,
Thomas
On 08/12/2015 09:18 AM, Guillem Jover wrote:
Hi!
On Wed, 2015-08-12 at 09:32:01 +0200, David Kalnischkies wrote:
[…] I wonder through if it isn't
a bug in dpkg(-source) to follow the symlink to the orig-tarball and
place the debian-tarball alongside it instead of placing the
debian-tarball alongside the symlink to the orig-tarball.
(Or did I misunderstand you?)
It's not really placing the files alongside, it just pipes the
tarballs into the filenames, which means that the symlinks are
followed. But see below…
----- Forwarded message from Thomas Nyberg <tomnyb...@gmail.com> -----
Date: Tue, 11 Aug 2015 17:30:29 -0700
From: Thomas Nyberg <tomnyb...@gmail.com>
To: de...@lists.debian.org
Subject: apt-get source symlinks if repository is local ('file:/)?
Message-ID: <55ca93a5.3030...@gmail.com>
-----------------------
drwxr-xr-x 5 xxx xxx 4096 Aug 11 17:16 package-0.1
lrwxrwxrwx 1 xxx xxx 81 Aug 11 17:16 package_0.1-1.debian.tar.gz ->
/repos/apt/ubuntu/pool/main/m/package/package_0.1-1.debian.tar.gz
lrwxrwxrwx 1 xxx xxx 71 Aug 11 17:16 package_0.1-1.dsc ->
/repos/apt/ubuntu/pool/main/p/package/package_0.1-1.dsc
lrwxrwxrwx 1 xxx xxx 77 Aug 11 17:16 package_0.1.orig.tar.gz ->
/repos/apt/ubuntu/pool/main/p/package/package_0.1.orig.tar.gz
-----------------------
-----------------------
[…]
dpkg-source -b package-0.1
dpkg-source: info: using options from
package-0.1/debian/source/options: --extend-diff-ignore=\.egg-info$
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building package using existing
./package_0.1.orig.tar.gz
dpkg-source: info: building package in
package_0.1-1.debian.tar.gz
dpkg-source: error: cannot write package_0.1-1.debian.tar.gz:
Permission denied
dpkg-source: error: gzip --no-name --rsyncable -9 gave error exit status 13
-----------------------
I.e. it's erroring out because it's trying to modify the file which is
symlinked to a file that my user doesn't own. Of course the solution is to
just copy the files over by hand an run again, but had I not had the repo
owned by anothe user, I could have accidentally modified it myself.
Is there a hidden option I'm missing that's turned this on? Can I turn it off?
It seems like very odd functionality and seems a bit unsafe.
There's no option to turn this behavior off. Adding an option to do
so, might be fine, but I don't think changing the default would be
ok, because it seems to me that if you are using a symlink farm and
request to regenerate the source, I'd take that to mean the user might
prefer to update the sources at their original location. Otherwise why
would you regenerate the source for the same exact version? :)
Thanks,
Guillem
