On Fri, Oct 17, 2014 at 03:51:04PM +0800, Thomas Goirand wrote:
> On 10/17/2014 01:41 PM, Bas Wijnen wrote:
> > Getting random packages from apt-cache rdepends debconf shows:
> >
> > - several packages that use debconf for questions that are only about
> > actions that don't need to be (and aren't) stored in config files.
>
> I previously thought that it was the case. Then thinking about it, it's
> often possible create configuration files for the sole purpose of being
> policy compliant and store values out of debconf.
Policy doesn't require values to be stored out of debconf. It only
requires that if settings are stored in configuration files, local
changes are preserved.
I saw some packages where I think it might be better to store the
settings in a configuration file, but for example there was also one
which stopped using a database. The question was "shall I remove the
database?" and if the answer was yes, the action was performed in
postinst. This isn't a setting, and it doesn't belong in a
configuration file. They may be relatively rare, but there are valid
cases for this.
> I see only one case where the output of questions from Debconf should
> not be stored: when it makes sense to *always* prompt (eg: when the
> maintainer really wants the question to be asked each time the package
> is upgraded). I do maintain packages with such a case.
That is another option, to which the previous is a variation (with the
detail that it can only be asked once, but it should be asked all those
one times. :-P)
> > - cxref uses ucf in postinst. This doesn't violate policy, but does (in
> > case of local changes) give the wrong default in the debconf question,
> > and an annoying "do you want to overwrite local changes?" after
> > answering the question.
>
> Without looking, this sounds like a "postinst modifies a CONFFILE",
> which indeed is a policy violation.
I didn't check, but I think all files this is about are not conffiles,
so there is no problem there. Maintainer scripts are allowed to modify
configuration files that are not conffiles.
The reason this question that looks like it is a conffile comes up is
that ucf tries to mimic how dpkg handles conffiles.
> > - esmtp starts by asking if you want to overwrite your config and
> > refuses to be configured by debconf if you don't. Also
> > policy-compliant
>
> This is debatable. To me, it doesn't make it policy compliant just
> because the frist debconf prompt makes it possible to not do anything.
I think it is (because it's not a conffile), but I don't really care:
it's not user-friendly, and should be improved.
> > - dvi2ps does something I don't understand... It asks questions but
> > never runs db_get. Presumably it pre-seeds some other package?
>
> Its looking like it doesn't need to do db_get. The only debconf
> templates which it has are of type "note", so it's not taking any decision.
I didn't look at the actual questions and didn't think of that. That
makes sense and there is obviously no problem with it.
> As I wrote previously, this may only happen if we decide to have such a
> library as essential, otherwise this forces to use pre-depends, which
> isn't good.
IMO using pre-depends is a lot better than adding a package to
essential, but I'd rather avoid both.
> Maybe we could even have what you're talking about directly in Debconf
> itself? I think it would make a lot of sense. If you want to work this
> out, please investigate the possibility to enhance Debconf directly,
> without needing to ship any supplementary lib.
#690390
Joey claimed that there was no problem ("A config script is a completely
general solution to that problem.") and then stopped answering.
> >> Then such a library *must* be marked as essential, and installed by
> >> default, otherwise it would break the install workflow.
> >
> > No; it's a _static_ library. It is included in the config script at
> > package build time.
>
> That's what I'm currently doing in all the OpenStack packages, and I'm
> not satisfied with this approach. I very much would prefer an
> enhancement of debconf itself.
On the one hand I agree (which is why I filed that bug), but on the
other hand it gives more flexibility if independent packages can provide
the functionality.
> > This means every binary package using it will have
> > a copy of the code in its maintainerscript.
>
> Which isn't nice.
True, but I don't really like the other options either.
- integrating it in debconf would probably be best, but I'm not going to
force it against the maintainer's will.
- adding an essential package is a huge price, which might be considered
after this is being used by many packages, but not while it's still
experimental.
- pre-depends don't even work: the config script runs before unpack, so
a pre-dependency is too late.
- Copying the code into every source package that needs it is a variant
of what happens now, where every package maintainer seems to write a
personal variation of it. Certainly not ideal.
> > A change in the library requires a rebuild of all the packages for
> > the change to take effect.
>
> Which doesn't scale archive wide if you find a bug.
If that becomes an issue, making it essential or merging it into debconf
could be considered. At this experimental stage, neither of those is
a good idea IMO.
> > That's not ideal, but better than marking it as essential, or making it
> > part of debconf (which would also work, but requires Joey Hess to accept
> > it, and so far he refuses to even acknowledge that there is a problem;
> > even if he would, I find making it a separate package a more elegant
> > solution).
>
> I don't agree with what you wrote above. Making it essential is a much
> better approach.
I am surprised that you consider adding a new essential package more
lightly than adding a pre-depends. To me, it is much heavier; a
pre-depends can be removed if it didn't turn out to be a good idea.
Any functionality that enters essential will practically have to stay
there forever.
> As for Joey Hess, he is a very reasonable person. If
> you come with a patch which is well written, and does enough to be
> helpful, I'm sure he'll accept it. If it's just bad, then probably he
> will refuse. I've seen this type of pattern multiple times with him.
I reported a bug, he said "this is not a problem", I explained why it is
and he didn't answer. I'm not inclined to write a patch in the hope
that he changes his mind, at the risk of my work being wasted.
> I've done this with a few lines of shell script. If that is what you
> want me to look into dh-parseconfig, then I don't think it's worth
> looking at.
Yes, this is a trivial script. It's also very short. The only reason I
want people to look at it is that I never made anything in Perl before.
> I've written this type of shell script in shell already. Though the
> issue is that it's currently very slow. You can have a look into
> openstack-pkg-tools, which holds the logic. However, really, the
> pkgos_inifile (inside pkgos_func) would need some rework to make it go
> faster. And I mean it: A WAY faster, not just stupidly horribly slow
> like it currently is.
How many gigabytes is your ini file? If speed is an issue, something
needs to be done about what's stored in there...
> > I don't have a bug tracker yet, but I can upload this to unstable if
> > people don't complain too much about the code. ;-) Then the bts can be
> > used for feature requests (and bugs of course).
I haven't seen any complaints about the code, although I think that is
because nobody looked at it. In any case, I'll upload it soon.
> Please don't upload this type of experimental software to Sid just right
> before the freeze. Please use experimental.
If I first write at least one library (which should be very easy, so I
think I'll do that), it is in a usable state for unstable. It doesn't
cause any problems for the freeze, so I'm not worried about it. If it
would enter testing (which I don't expect; it also needs to go through
NEW and I would need to be confident enough not to file a serious bug;
not sure about that yet), there isn't any problem either; it would
simply mean that users can develop on Jessie with this functionality.
There's nothing wrong with that, and it breaks nothing. I don't expect
many people to install it if it would be part of the release.
> > The library is meant to make common operations easy. If a package has
> > special needs, it must still implement its parsing by itself.
>
> Well, no. What's the point then? To make your piece of software useful,
> you must address as many cases as possible.
No, I disagree. The point is similar to common-licenses. I want to
avoid duplication in the archive. At this moment every package that
uses debconf should have near-identical code in it. I want to place the
source of this code in a central location. I don't want to burden all
those packages with a huge library, most of which they don't use.
It would be possible to split it up, and have a different file to
include for different needs. Then the full-featured huge library is
only included by those packages that use it, and the small limited
library is used by all others. I'm certainly not against that, and the
architecture I set up supports it. I'm not planning on writing such a
full-featured library, but I've made sure that anyone else can make that
work even in the unlikely event that I don't cooperate.
> Yeah, but then this can be implemented within the library, on top of the
> functions you mentioned.
Yes, but I don't want to add code that hardly any package uses to all
(debconf-using) packages out there. So it's a trade-off between amount
of code and how many packages use it.
Thanks,
Bas
Attachment:
signature.asc
Description: Digital signature