Re: RFS: FSlint - File System lint
Yaroslav Halchenko <debian@onerussian.com> wrote:
Can you please invest in some empty lines between your text and the text
you quote? This is hardly readable. Thanks.
>> >> > 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?
>> > >...<
>> Of course a change in the debian revision will also trigger the
>> buildds.
> that is good that we agree... so what was about your statement:?
Well, if the package you uploaded as debian-native has a packaging
error, or just needs to be adapted to newer Debian requirements, you
have two choices: Either release a new upstream version, which has has
no changes relevant for anybody except the Debian buildds. This will
confuse your non-Debian users. Or switch from Debian native to
non-native packaging - better do that in the first place.
If you've packaged it as non-native from the start, we end up in the
situation described below:
>> >> release a new upstream version just because you need to change a
>> >> build-depends and trigger a rebuild on the Debian buildds?).
>
>> 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).
> that is ok to my knowledge
It is okay, but it's confusing by itself.
>> In the -1 version,
> -1 version? may be you meant debian revision? may be -2?
Sorry, yes, I meant debian revision -2.
>> 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.
> can you describe what is confusing in that? I don't really see it... you
> don't operate on diff.gz directly anyways -- you are operating on
> extracted (and may be even patched) source, so you have all the files.
I often operate on diff.gz files. It's easy to look into them, just
"less ...diff.gz", and you can check whether the copyright file is okay,
whether it uses dpatch, cdbs, whatever, whether a particular patch has
been applied, and so on.
> Usually you are inspecting .diff to catch what was done wrong, or if
> there was garbage sucked in, or to extract relevant patch. If .diff.gz
> was missing debian/ it is obvious (to me) that debian is within
> orig.tar.gz due to the definition of diff.gz
If the diff.gz is missing a Debian directory, the first thing I'd
suspect would be that something went badly wrong. After finding out
that the directory is in the orig.tar.gz, I'd go on checking in the
copyright file whether any repackaging is described. If I find no
information about that, I'd think about two possibilities: Either the
debian directory is in the orig.tar.gz file, or the packages didn't
document their repackaging. For both cases, the best approach would be
to file a bug...
>> > 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.
> ok - let me make an analogy to describe what I meant: "this book
> containing fairy tales from around the world was written especially for
> our kindergarden"...
And you expect that the kindergarden in the neighborhood will not be
interested, never? And you also expect that the people working there
will never get a different opinion how a fairy tale book should look
like? If the people working with the newest group of younger children
try out something new (i.e., Debian policy is changed for the next
release), shouldn't the book be still the same for the ones working with
the older groups?
>> How can the Debian policy "forbid" something that upstream is doing?
> :-) Good questions with simple answer: it can't. That is why over and
> over again everyone advices upstreams to place /debian directory aside
> of orig.tar.gz. And lest don't get into the loop describing why it is
> bad... ooo - actually it might be worth to compose a wiki page where
> people can add to pros/cons...
I've never read a pro, except "I'm both upstream and Debian maintainer,
and it's convenient for me", which is a short-sighted argument.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: