On 16/06/15 20:14, Anto wrote:
>
>
> On 16/06/15 16:40, Isaac Dunham wrote:
>> On Tue, Jun 16, 2015 at 11:09:43AM +0200, Anto wrote:
>>>
>>> On 16/06/15 10:58, Arnt Gulbrandsen wrote:
>>>> Anto writes:
>>>>> Yes. I almost have everything to start trying to build epoch package,
>>>>> *except* one important point that I have been asking for. That is the
>>>>> mechanism to trigger an action to automatically update epoch.conf and
>>>>> start the daemon when we install all packages with daemons that
>>>>> need to
>>>>> be started/stopped at boot/shutdown time, *without* including epoch
>>>>> specific files into those packages. So what I am basically looking
>>>>> for
>>>>> is totally different approach than what Debian based distros have
>>>>> been
>>>>> doing for other init systems, so that we don't need to patch all of
>>>>> those packages with epoch specific files and re-build them.
>>>> You have code that rescans /etc/init.d and parses those LSB-Foo-Bar
>>>> comments, is that right? If so, you have three options:
>>>>
>>>> 1. Piggyback on someone's post-install hooks.
>>>> 2. Run inotify() in a patched epoch and watch for file creation in
>>>> /etc/init,d
>>>> 3. Invent a new hook that lets you process ALL dpkg -i calls.
>>>>
>>>> Pick your poison.
>>>>
>>>> Arnt
>>>>
>>> Thanks a lot Arnt,
>>>
>>> Option 1 is definitely not what I am looking for. Option 2 looks to
>>> be the
>>> most elegant solution, assuming that all packages will still
>>> generate their
>>> sysvinit files on /etc/init.d.
>>
>> If you were open to option 1, you could install your own update-rc.d
>> if you conflicted with sysvinit.
>>
>> The init scripts are *not* generated: they are config files that are
>> included in the package, but will not be replaced if modified unless
>> you specify to replace them.
>> But watching for file creation seems like a case of refusing to work
>> with the package manager.
>>
>> For option 3:
>> https://wiki.debian.org/DpkgTriggers
>>
>>
>> HTH,
>> Isaac Dunham
>>
>
> Hello Isaac,
>
> Thanks for mentioning about DpkgTriggers. I will read that later on.
>
> I was not really sure if script similar to update-rc.d would be
> relevant to epoch as the way the runlevel is being managed in epoch is
> different from sysvinit. That is why I am looking for other options.
>
> So far, especially for PCs with sysvinit, the only option that I see
> is to monitor the /etc/init.d and update epoch.conf base on the new
> file being created on that directory. I imagine that happens after the
> PC boots with epoch and at one point we install ntp package for
> instance. At this point, do you think we could tell the package
> manager to update epoch.conf after it finishes with the installation
> of ntp package, like the way the package manager runs initramfs-tools
> after we install/uninstall kernel? If so, that will be great. Oohh...
> wait... is this the function of DpkgTriggers? But could we implement
> that outside epoch and ntp (my example above)?
>
> Cheers,
>
> Anto
>
Hello Issac,
After reading
http://sources.debian.net/src/dpkg/1.18.1/doc/triggers.txt/ (over and
over), it looks that dpkg-trigger is a better solution than monitoring
/etc/init.d using inotify(). However, I still fail to understand some
points.
It looks that the only entity who has all knowledge on what is going on
during the trigger event is dpkg. How do we forward that trigger event
information to the triggered (or consumer) package, so that it knows
which package (or producer) initiates that trigger and what kind of
action is being done?
For instance, we set a trigger on epoch package for any updates on
/etc/init.d. At one point after booting with epoch, we install ntp
package. How can we make the postint script of epoch package knows that
ntp package is being installed and /etc/init.d/ntp file is being added?
The requirement that needs to be fulfilled for that are, there must not
be any script being added into ntp package and no program/script with
inotify() function on epoch package to monitor /etc/init.d. Would that
be possible?
Thanks in advance.
Cheers,
Anto