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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
