On Thu, Mar 05 2009, Russ Allbery wrote:
> Ben Finney <ben+deb...@benfinney.id.au> writes:
>
>> It's been brought to my attention that this approach actually conflicts
>> with the above section of policy.
>>
>> Am I right in thinking that the ‘get-orig-source’ target should ignore
>> the version strings in ‘debian/changelog’, and should instead get
>> whatever version is the latest available from upstream?
>
> I think the way that you're using it is more useful (and possible) than
> doing what an exact reading of the current text would indicate, and I do
> the same thing that you're doing.
>
However, as written, the wording does suggest that the latest
version is what will be acquired, and any shift in meaning will make
currently conforming packages buggy.
> http://bugs.debian.org/466550 is somewhat related.
>
> For packages with non-trivial rules to generate the upstream source
> tarball used with Debian, it's very difficult or impossible to write a
> future-proofed version of that cdoe that will work with arbitrary future
> versions from upstream. However, documenting the method used to generate
> the *current* version will let people modify that target as needed to
> package future versions.
I beg to differ. It would be hard for me to assure that any rule
run which looks at the debian/changelog version will actually work at
any time in the future.
I have upstreams that ship released software tarballs that match
a pattern I can feed uscan; but older versions are often purged from
the site quickly. I can, then, use the pattern to download the latest
version (perhaps using uscan), and then unpack it, rm -rf the debian
directory, and repack it, preserving the version number, without much
hassle.
Given that at least one version of the software is guaranteed to
exist, I can craft a generic get-orig0source rule that will work -- but
if I pay attention to the versoin, the rule will fail just days or
weeks after upload.
Making people remove a generic get-orig-source that actually
gets the latest source package from upstream by making it violate the
new version of policy would not be a good thing, in my opinion,
Silenty reverting the original meaning of the target, without a
transition plan, instead of creating a new target with the new meaning
is not usually how Debian policy used to work.
I am wondering which is of more use to the end users as well: I
can always get the sources of the package I have already on my disk
from Debian, but getting the latest munged source seems more useful to
me.
manoj
--
You may have heard that a dean is to faculty as a hydrant is to a
dog. Alfred Kahn
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
