Re: RFS: FSlint - File System lint
> >> > 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:?
> >> 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
> In the -1 version,
-1 version? may be you meant debian revision? may be -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.
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
> > 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"...
> > 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.
indeed, I think that at least mentioning the confusion which comes once
so often, it might be useful to at least trigger the change (I bet
others can come up with better statement than mine)
> >> > 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?
:-) 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...
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
Reply to: