> > especially if a package maintainer is the upstream.
> This isn't an argument for inclusion of the debian directory (will you
> release a new upstream version just because you need to change a
> build-depends and trigger a rebuild on the Debian buildds?).
yikes... pardon my ignorance if it is not so... quick look at dev-ref
didn't allow me to find a statement that boost in debian revision
doesn't cause triggering of buildd.
you are saying that increment in debian revision doesn't trigger buildd?
So if I fix a security bug and increment debian revision, that doesn't
penetrate to other architectures?
if buildd is triggered by deb revision increment as well -- there is no
difference between boosting of the upstream version or only deb
revision...
> > And also I don't see any strict requirement
> > (although I understand that it is desired) to don't use native
> > versioning schema for not-only-for-debian packages.
> I don't see this written out specifically, either, but I think this is
> implied. For example, 3.2.1 talks about native packages:
> ,----
> | Native Debian packages (i.e., packages which have been written
> | especially for Debian) whose version numbers include dates should
> | always use the "YYYYMMDD" format.
> `----
well -- that is only for the "Version numbers based on dates" and from
the same section "In general, Debian packages should use the same
version numbers as the upstream sources". If you cited it to
characterize what native package is, then we can debate on the meaning
of "packages which have been written especially for Debian".
First of all *any debian package is written especially for Debian*,
so there is a bit of tautology. Package itself is not a software or
documentation, it is a packaging material (ie debian/) accompanying the
content.
Cleaner statement may be something like "i.e. if the packaged material
(e.g. software, images, documentation) is intended to be used primarily
on a Debian-based system and useless on the other systems". That seems
to be cleaner.
> > I think that policy/dev-ref is not clear on that at the moment, that
> > is why relevant questions come up from time to time.
> Yes, but the answers given are always the same: Try to avoid a
> debian/ directory in the upstream sources. It's in the archives.
yeap - I saw most of those. And I saw the arguments. And I agree that
having split debian/ helps in few cases. But the same question arises
over and over. May be it is the time to fix the policy to make it
explicit to avoid the debates.
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
Attachment:
pgpvEv35wRGBR.pgp
Description: PGP signature