Bug#557667: dpkg-dev: behaving differently wether quilt is installed or not
Gerfried Fuchs
Version: 1.13.26
Severity: important
Hi!
Given the recent thread on debian-devel I'm filing this as bugreport.
Behaving differently wether quilt is installed or not is working against
the principles of least surprise, results in FTBFS in certain areas, and
is a hassle.
Fix for this would be to Depend on quilt to make sure that it's always
installed and make dpkg-source -x behave *exactly the same* all the
time. Another fix for it would be to make dpkg-source -x be able to do
that even without quilt installed. But it is important to have
dpkg-source behave idempotent, otherwise there will be lots of different
areas things can (and will) break.
Thanks,
Rhonda
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raphael Hertzog
found 557667 1.14.25
thanks
On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> Version: 1.13.26
The etch version has no support of new formats at all... :)
> Behaving differently wether quilt is installed or not is working against
> the principles of least surprise, results in FTBFS in certain areas, and
> is a hassle.
Would it be more acceptable if it could no more lead to FTBFS at all?
What other hassle have you identified apart from the problem that you
can't use quilt if you had it not installed at unpack time?
> Fix for this would be to Depend on quilt to make sure that it's always
> installed and make dpkg-source -x behave *exactly the same* all the
> time. Another fix for it would be to make dpkg-source -x be able to do
> that even without quilt installed.
What do you mean by "do that"? Creating the .pc directory used by quilt?
> But it is important to have dpkg-source behave idempotent, otherwise
> there will be lots of different areas things can (and will) break.
I'm all for fixing dpkg-source to avoid those breakage when you discover
them but I don't want to have dpkg-source recreate .pc without using quilt
and guillem would like to avoid the quilt dependency.
Cheers,
--
Raphaël Hertzog
Gerfried Fuchs
thanks
* Raphael Hertzog <her...@debian.org> [2009-11-23 22:14:01 CET]:
> notfound 557667 1.13.26
> found 557667 1.14.25
> thanks
Sorry. :)
> On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> > Behaving differently wether quilt is installed or not is working against
> > the principles of least surprise, results in FTBFS in certain areas, and
> > is a hassle.
>
> Would it be more acceptable if it could no more lead to FTBFS at all?
That's a bit overrated, please keep the discussion to a sensible level.
Though, either it should built conflict with quilt, or build-depend on
quilt, or not produce FTBFS in these areas. This is one big reason to
*not* switch to default 3.0 (quilt) source format.
> What other hassle have you identified apart from the problem that you
> can't use quilt if you had it not installed at unpack time?
None that I am yet aware of but I'm not certain that there are no
others. Not having dpkg, as a toolchain program, behave reliable in
exactly the same way in all areas is just calling for troubles,
possibly forseeable and not yet forseeable ones.
> > Fix for this would be to Depend on quilt to make sure that it's always
> > installed and make dpkg-source -x behave *exactly the same* all the
> > time. Another fix for it would be to make dpkg-source -x be able to do
> > that even without quilt installed.
>
> What do you mean by "do that"? Creating the .pc directory used by quilt?
Yes, so that dpkg-source -x behaves exactly the same, no matter wether
quilt is installed or not.
> > But it is important to have dpkg-source behave idempotent, otherwise
> > there will be lots of different areas things can (and will) break.
>
> I'm all for fixing dpkg-source to avoid those breakage when you discover
> them but I don't want to have dpkg-source recreate .pc without using quilt
> and guillem would like to avoid the quilt dependency.
Then we are at a deadlock here and this means the dead for the push of
3.0 (quilt) as default, sorry. You claimed that quilt using packages
won't need to change anything, now it turns out that the quilt handling
has to be removed - and given that things *have* to be changed switching
the default can't happen.
Feel free to close this bugreport when you remove the intention to fix
#553928 without making it a wontfix. :) Unfortunately I don't see any
other way round that.
Thanks. :)
Rhonda
Raphael Hertzog
> block 553928 with 557667
It's not up to you to decide such things...
> > Would it be more acceptable if it could no more lead to FTBFS at all?
>
> That's a bit overrated, please keep the discussion to a sensible level.
The remark is serious, I committed changes so that when dpkg calls quilt
it will behave as strictly as the internal dpkg-source implementation. So
you will no longer have FTBFS due to fuzzy patches. It will fail to build
the source package on the maintainer machine directly (until he refreshes
the patches).
The only remaining known problem is the one you where you unpack without
quilt and try to use quilt afterwards. And this one doesn't have to wait
that this bug is fixed but that all buildd use an sbuild recent enough
so that the source package is extracted in the build environment (so
build-depending on quilt is enough to ensure that it's properly unpacked).
> > I'm all for fixing dpkg-source to avoid those breakage when you discover
> > them but I don't want to have dpkg-source recreate .pc without using quilt
> > and guillem would like to avoid the quilt dependency.
>
> Then we are at a deadlock here and this means the dead for the push of
> 3.0 (quilt) as default, sorry. You claimed that quilt using packages
> won't need to change anything, now it turns out that the quilt handling
> has to be removed - and given that things *have* to be changed switching
> the default can't happen.
I might change my opinion though, after discussing with quilt's upstream,
he thinks it's reasonable to recreate the .pc even without quilt.
Cheers,
--
Raphaël Hertzog
Gerfried Fuchs
> On Wed, 25 Nov 2009, Gerfried Fuchs wrote:
> > block 553928 with 557667
>
> It's not up to you to decide such things...
It's no decision, it's a fact that the resolution of this is hindering
switching the 3.0 (quilt) format on by default, I don't know what this
has to do with any "deciding".
> > > Would it be more acceptable if it could no more lead to FTBFS at all?
> >
> > That's a bit overrated, please keep the discussion to a sensible level.
>
> The remark is serious, I committed changes so that when dpkg calls quilt
> it will behave as strictly as the internal dpkg-source implementation. So
> you will no longer have FTBFS due to fuzzy patches. It will fail to build
> the source package on the maintainer machine directly (until he refreshes
> the patches).
dpkg won't be able to make package "no more lead to FTBFS at all",
there will always be areas out of the scope of dpkg that lead to
FTBFSes. Or you meant something different, but then I have no clue on
what you meant with it.
> The only remaining known problem is the one you where you unpack without
> quilt and try to use quilt afterwards. And this one doesn't have to wait
> that this bug is fixed but that all buildd use an sbuild recent enough
> so that the source package is extracted in the build environment (so
> build-depending on quilt is enough to ensure that it's properly unpacked).
Sorry, but you said yourself, don't sweat on sbuild too much. Actually,
having sbuild "fixed" would be a workaround for the core problem, and
won't solve that dpkg is behaving differently with quilt installed or
not. But I'm repeating myself and will refrain from iterating this
discussion again in case you don't bring up anything new.
You are aware that dpkg is most probably the most central tool for
Debian (and its derivates) and actually it is crucial that it behaves in
a clear defined way and not differently depending on other packages
installed or not. The current situation isn't giving this, and that
alone should be reason enough against this format as default.
> > Then we are at a deadlock here and this means the dead for the push of
> > 3.0 (quilt) as default, sorry. You claimed that quilt using packages
> > won't need to change anything, now it turns out that the quilt handling
> > has to be removed - and given that things *have* to be changed switching
> > the default can't happen.
>
> I might change my opinion though, after discussing with quilt's upstream,
> he thinks it's reasonable to recreate the .pc even without quilt.
If that works in a relieable way and dpkg won't behave differently when
quilt is installed or when it is not installed then that might be called
a solution to the situation, indeed.
So long,
Rhonda