Re: RFS: FSlint - File System lint
Yaroslav Halchenko <debian@onerussian.com> wrote:
>> > 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...
Of course a change in the debian revision will also trigger the
buildds. But this situation is exactly the problem I was referring to:
In the -1 debian revision, you'd have a non-native package with an empty
diff.gz file (don't even know whether dpkg-source will accept that). In
the -1 version, you would have a diff.gz file that contains only a diff
against debian/control and debian/changelog. Now this would be very
confusing. Especially if there is a bug in the packaging and you are
currently not available: A possible NMUer would be very confused.
>> ,----
>> | Native Debian packages (i.e., packages which have been written
>> | especially for Debian) whose version numbers include dates should
>> | always use the "YYYYMMDD" format.
>> `----
[...]
> 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".
Yes, I cited it because of this.
> 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.
"package" in this context is also the name for software here. And for
sure a package is *not* just the packaging material; a Debian source
package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, and
a binary package is a deb file.
> 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.
Submit this as a wishlist bug to the policy.
>> > 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.
How can the Debian policy "forbid" something that upstream is doing?
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: