[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: native pkg versioning (was Re: Question about native packages)



On Sun, 04 Feb 2001, Manoj Srivastava wrote:
> >>"Henrique" == Henrique M Holschuh <hmh@debian.org> writes:
> 	I don't see where the source or binary package enter the
>  picture here. What am I missing?

Currently, policy says NOTHING about native packages and debian revision
fields. That means a native package (both source==.tar.gz+.dsc and the
binaries==.deb) can, *if they want*, have a debian version field ('-1') as
well as the upstream version field.

I want to forbid native SOURCE packages (i.e.: the .tar.gz+.dsc) to have
such version fields, and to say nothing at all about native .debs (because I
could care less about native .debs with a debian revision field -- the
problem I want to fix happens only in source packages).

Normally, that means the native .deb will NOT have a debian version field.
However, if a porter or autobuilder wants to tack one to a .deb and make a
binary-only NMU, I was not going to forbid it in policy.

> 	Are you saying I have
>  bar_1.1.tar.gz
>  bar_1.1.dsc
>  bar1_1-13_i386.deb
> 	?

Right now you COULD have the above, yes. I was not going to forbid it in my
policy proposal, because it is not important to the problem I am trying to
solve.

>  I want to have
>  foo_1.1.dsc
>  foo_1.1.tar.gz
>  foo_1.1_i386.deb
> 
>  bar_1.1.orig.tar.gz
>  bar_1.1-13.dsc
>  bar_1.1-13.diff.gz
>  bar_1.1-13_i386.deb

What I am going to propose is not going to forbid any of the above, either.

But the proposal *will* forbid:
foobar_1.1-2.tar.gz
foobar_1.1-2.dsc

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Attachment: pgp3uMEuEDiHl.pgp
Description: PGP signature


Reply to: