Re: This topic died off; any resolution?
- To: debian-devel@lists.debian.org
- Subject: Re: This topic died off; any resolution?
- From: Raphael Geissert <atomo64+debian@gmail.com>
- Date: Thu, 02 Apr 2009 11:39:19 -0600
- Message-id: <[🔎] gr2t73$8sm$1@ger.gmane.org>
- References: <20090325190038.2caa43e9@brennin.fionavar.dd> <878wmtc7vq.fsf@windlord.stanford.edu> <878wmq8dg6.fsf@anzu.internal.golden-gryphon.com> <87iqluxdd1.fsf@faui44a.informatik.uni-erlangen.de> <877i276i7x.fsf@anzu.internal.golden-gryphon.com>
Manoj Srivastava wrote:
> On Sat, Mar 28 2009, Reinhard Tartler wrote:
>
>> Manoj Srivastava <srivasta@debian.org> writes:
>>
>>> A special rule in debian/rules to duplicate apt-get source for
>>> people who are skeptical of thea rchive (and have an ill defined
>>> attack vector thay are being paranoid about) -- or to provide
>>> functionality that apt-get source is not a duplicate for?
>>
>> Well, for complicated cases (like ffmpeg, where we have to fight with
>> svn:externals, external svn servers etc) it is very helpful to have such
>> a rule. Espc. if some user objects with some of the modifications and
>> needs to apply changes to it in order to get a slightly modified
>> package.
>
> If you are talking about cases where there is no upstream
> tarball, and just SVN (or some other VCS), and these cannot be handled
> by uscan, then I agree, it would be nice to standardize the calling
> interface.
I planned to add support for svn in version 4 watch files (it would be a
matter of svn info svn://domain.tld/path/to/repo and some data massaging).
But well, now that everyone is talking about it why not just tell what is
missing so that it can be addressed in version 4 watch files?
> My slight preference is a script with a well known name, since
> that script can then be extracted and used by DEHS/PTS like systems,
> without requireing that the whole source be unpoacked and
> ./debian/rules be runnable (I have sanity checks in my debian/rules)
>
What you want is #458789, which should be tagged wontfix because of all its
implications (extra needed packages, security risk, etc).
Cheers,
Raphael Geissert
Reply to: