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

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: