Re: dpkg-buildpackage -ucb
On Thu, 2016-04-28 at 14:10:20 +0200, Johannes Schauer wrote:
> > Guillem Jover writes ("Re: dpkg-buildpackage -ucb"):
> > > I'd rather just finish and merge the no signing by default code, as
> > > proposed in #733029 (uh from 2013-12 already…), and merge also the
> > > configuration file support for dpkg-buildpackage in dpkg 1.18.6.
>
> \o/
>
> with my sbuild hat on: Will the -us -uc options continue to work and mean
> "don't sign anything"? Sbuild somehow has to be able to work with dpkg from
> chroots from oldoldstable up to unstable. Will it be required from sbuild to
> detect dpkg versions and pass different signing options?
Yes, I don't see the options disappearing. The command might grow a
new option that is less scary than --force-sign to enable signing, but
these will remain in case you want to override a local config default
for example. They might also grow long name versions eventually (I
think I might even have the change somewhere!).
And an hipothetical removal like that (which again will not happen :),
for such an extremely used interface would imply a long-winded transition
of several Debian releases: 1) default switch, 2) emit warnings,
3) options removal; and only that if there would be no visible users.
> > > For dpkg 1.18.5 I've reworked the built type selection by adding a single
> > > --build option with comma-separated components "source", "any", "all" and
> > > "full", to try to improve the current unintuitive mess.
> >
> > I hadn't spotted this going in.
Sorry, should have qualified with "locally", although I was going to
push today or so. :) I've now attached the patch sitting in my local
branch that I'm planning to push.
> I haven't had a look in the source code by my intuitive understand would be:
>
> - source: build the source package
> - any: build architecture:any binary packages
> - all: build architecture:all binary packages
> - full: the same as source,all,any
Exactly right!
> Assuming that I guessed the meaning right, I find the naming very intuitive. I
> think it is easy to remember what "any" and "all" mean from the Architecture
> field. Building just the debs would be possible by saying --build any,all.
>
> For reference, sbuild uses the following command line switches:
>
> --arch-any/--no-arch-any: build/don't build architecture:any binary packages
> --arch-all/--no-arch-all: build/don't build architecture:all binary packages
> --source/--no-source: build/don't build the source package
>
> This is similar to the choice of "source", "any" and "all" for the new --build
> option and if the meaning is indeed as I suspect it is, then this fits nicely
> together I think.
Yes.
On Thu, 2016-04-28 at 17:30:59 +0100, Ian Jackson wrote:
> > Quoting Ian Jackson (2016-04-28 13:45:46)
> > > Is it too late to change this ? Maybe `aall' for `architecture: all'
> > > and `all' for `everything including source' ?
IMO it's never too late for this kind of thing! But it needs to be
worth it or it needs to be an improvement, see below.
> I guessed that that was what it meant. ISTM that it's what a Debian
> insider would think.
>
> But, I have had some experience recently helping people who are not
> very familiar with Debian development build their first packages from
> source, and that kind of thing. I would like it to be easy for a
> non-expert user to get the source for a Debian package and build it.
>
> I really don't relish the thought of having to explain to such people
> that
> dpkg-buildpackage --build=all
> actually builds a small subset of the outputs (and, often, not the one
> they wanted).
I'd say these people should be told to use just «dpkg-buildpackage».
And the signing by default for example is a common cause of confusion,
because it tries to sign with the maintainer's key. But once that's
changed then using just that call is the easiest way to go about. The
documentation should then be clear about what each of these options
and values means, for further digging and more advanced users.
I'll try to cover my train of though here to give some context.
Recently I was doing cleanup in the build options support to both
dpkg-buildpackage and dpkg-genchanges, and I realized that having added
the -g and -G options was a bad mistake and should have instead added
the more generic --build at the time. Even I often have to check the
docs or --help to see what some of the -b/-B/-A/-g/-G/-S/-F options do!
When adding the new --build option I initially thought about using
“source”, “arch-indep”, “arch-dep”, but those are pretty long to type
(not to mention that «dep» is a pretty overloaded term that could
easily be a short form for dependency), using instead “arch” and “indep”
while shorter, are inconsistent (yes I know we have debian/rules targets
with similar names, yes I think they are also “wrong” :). Both are binary
packages, one is arch independent, the other is arch dependent or
specific. Then it came to me that the shortest probably most obvious way
to name the values was to use the same names we use for the Architecture
field. Which I concede can be seen as also confusingly named, but it's
something that you have to learn pretty early on when dealing with Debian
packaging, as you'll get arch «all» in *.deb packages, and you'll see
«any» in control files, and build dependencies and similar. I mildly
discarded using «src» becuse none of the other were abbreviations.
To match our current -F option I added an alias value of «full» so that
you don't have to type as much. I think the name is good (short and
unambiguous), and at the time the -F option was proposed I pondered about
using other names but found that full described it the best.
But in the end I concluded that even if people end up not liking the
names much, we can always add more aliases, because in comparison to the
single-letter options these are values instead! Of course adding
aliases also has a cost and will also be confusing, but it's easy to do
and does not break anything.
> Can we not manage to use `indep' for this ?
>
> Eg,
> source | src source package
> indep arch:all binary packages
> arch arch:any or arch:<specific> binary packages
> deb | ??? the complete set of binary packages (=indep,arch)
> all all of the above (=deb,src)
As mentioned above, I think the arch/indep names are not very good,
even if we have precedent in the distribution. And I also find that
using «all» here would be quite confusing.
Also being consisten with other similar tools such as sbuild is
important to avoid even more confusion.
I'd be fine with adding «binary» as an alias for «any,all». Or perhaps
also adding «bin»/«src» as aliases for «binary»/«source», so that we
don't have to type as much.
> I'm tempted to suggest
> --no-build=src
> --build=no-src
> too.
Adding negations would be an option, but those can be added at any
time later on if need be.
Thanks,
Guillem
Reply to: