Re: debconf as a registry
On 10/18/2014 05:14 AM, Bas Wijnen wrote:
>> 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.
It's not, because you break the debconf prompts workflow if you use
pre-depends. Normally, it goes this way:
- download all packages
- answer all debconf prompts
- packages gets installed
With a pre-depends, it goes this way:
- download all packages
- answer *some* of the debconf prompts
- *some* packages gets installed, including the pre-depends
- the package that needed the pre-depends shows its debconf prompts
- the rest of the packages gets installed
Clearly, I don't want the later, it's really not cool at all, especially
when you install so many packages and get so many prompts during the
installation process. BTW, this happens often with dbconfig-common, and
I really wished dbconfig-common was made "Priority: required", just like
debconf. I prefer to have every prompts at once, before installing any
package. So for what I do, a pre-depends is not at all an option.
>> 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.
Well, I don't think your bug entry is at all useful without any patch
attached. Also, Joey isn't an all-mighty god, and doesn't get to decide
for everything, even though most (including me) respect him a lot.
Debconf is by the way team maintained. We can collectively decide for
this type of change, *if* we have some convincing patch / add-on to add
in Debconf.
> - integrating it in debconf would probably be best, but I'm not going to
> force it against the maintainer's will.
See above.
> - 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.
True. So let's do the work and make it a super-nice solution! :)
> - pre-depends don't even work: the config script runs before unpack, so
> a pre-dependency is too late.
It works, but it's not user friendly (see above). Also, we try to avoid
pre-depends as much as possible.
>>> 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.
I agree that it's not a solution for *now*, but we should keep in mind
that this is what we should aim for.
>>> 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.
If it becomes an archive-wide well-recognized solution, then having the
package as essential *or* having it included in debconf (which has a
Priority: required) achieves the same result.
> 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.
Probably the way to go is to do what you said first: have the lib being
included in packages, and if it turns out well, see how we can improve
the situation. But definitively, having a built-using: on so many
packages doesn't scale.
> 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'm not a Perl person, so I can't help if you choose Perl.
>> 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...
Quite big. Multiple thousands of lines easily...
Cheers,
Thomas Goirand (zigo)
Reply to: