Russ Allbery dixit:
>local-options means that the maintainer sees a very different view of the
>package than any other consumer on the package via the archive. Not only
Right, but the packaging workflow is the same (and since there is only
one quilt patch, the view other developers have pretty
Thorsten Glaser writes:
> Ian Jackson dixit:
>> The problem is that `3.0 (quilt)' has both advantages (eg that
>> `nativeness' is declared explicitly) and disadvantages (patches stored
> Not necessarily:
> | $ cat rs/debian/source/local-options
> |single-debian-patch
> | $ cat
Ian Jackson dixit:
>The problem is that `3.0 (quilt)' has both advantages (eg that
>`nativeness' is declared explicitly) and disadvantages (patches stored
Not necessarily:
| $ cat rs/debian/source/local-options
|single-debian-patch
| $ cat rs/debian/source/local-patch-header
|Please review
Hi,
On Fri, Jun 12, 2020 at 3:30 AM Ian Jackson
wrote:
>
> As for `3.0 (native)', it has one serious disadvantage: dpkg-source
> has been programmed to reject version numbers with a Debian revision.
> If that restriction were relaxed, `3.0 (native)' would be a strictly
> superior drop-in
Felix Lechner writes ("debian-policy: Please permit Debian revisions with 1.0
native packages"):
> As a Lintian maintainer, I would like to express support for Ian's
> effort to remove restrictions on Debian version strings.
>
> Unlike Ian, however, I also believe all packages should be
Jonathan Nieder writes ("Re: debian-policy: Please permit Debian revisions with
1.0 native packages"):
> Hi,
>
> Sam Hartman wrote:
>
> > I think there are at least two cases where this issue comes up and is
> > important, and where using a debian revision without separate upstream
> > tarballs
On Fri, Jun 12, 2020 at 09:09:22AM +, Holger Levsen wrote:
> hi,
>
> I'm not fully sure if people really intend to change the 1.0 format, but if
> so,
> I'm against it. If you do it, please call it 1.1 or whatever, but please don't
> change 1.0, too many tools rely on it's decade old
hi,
I'm not fully sure if people really intend to change the 1.0 format, but if so,
I'm against it. If you do it, please call it 1.1 or whatever, but please don't
change 1.0, too many tools rely on it's decade old behavior.
Besides that it's also my opinion that we should get rid off native
Hi,
Sam Hartman wrote:
> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision
I strongly agree with Ian in this matter.
I think there are at least two cases where this issue comes up and is
importand, and where using a debian revision without separate upstream
tarballs is the right approach:
1) small packages currently maintained by the upstream maintainer where
debian
Hi,
As a Lintian maintainer, I would like to express support for Ian's
effort to remove restrictions on Debian version strings.
Unlike Ian, however, I also believe all packages should be converted
to format 3.0. A package's 'nativeness' is then declared explicitly,
and does not have to be
11 matches
Mail list logo
