[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Suggestion: quilt



On Mon, 2005-04-04 at 09:33 -0400, Toshio wrote:
> On Mon, 2005-04-04 at 08:47 +0200, Adrian Reber wrote:
> > On Sun, Apr 03, 2005 at 01:54:34PM -0400, Toshio wrote:
> > > - Changed some of the entries in the %%files section to own more
> > >   directories, add more docs, and mark config files as config.
> > 
> > How about marking config files also as noreplace? 
> When should config files be noreplace and when should they not?  We
> can't tell when we build this version of quilt whether a later version
> will make an incompatible change to the quiltrc config....

You don't have to.  When you do know it, ie. when packaging the next
version, you can set them as appropriate.  IIRC, it's the %config(foo)
from the _new_ package that apply when upgrading, not the old one.
Setting noreplace in the initial import might be polite in case someone
upgrades from a non-FE package if you assume that the old config will
work for your new package version.  If you don't think it will, don't
set noreplace.

> > And I really don't
> > think that this package should own /etc/bash_completion.d/ because it is
> > already owned by the bash-completion package.
> 
> Since this package doesn't depend on bash-completion, it has to own the
> bash_completion.d directory unless...
> 
> > How about using a trigger for the bash-completion stuff like I have seen
> > it in other packages (mpc).
> 
> ...you create a different mechanism to deal with it.  I was unaware of
> the trigger stuff you refer to but it looks almost right::

Owning /etc/bash_completion.d would be much simpler.  The only package
that really benefits from the supplemental bash_completion.d snippet
triggers is bash-completion itself as it cannot guarantee that the utils
corresponding to those config snippets are available (and even then, it
wouldn't be _that_ big a deal, but I'm leaving the triggers in because
they are already there, and have no known problems).  When installing
quilt, you _do_ know that the required executables will be available, so
you can just drop the bash-completion snippet in, and things will work.

> I don't use triggers much but I think this doesn't handle the case where
> bash_completion is installed and quilt/mpc gets uninstalled.  So it also
> needs::
>   %postun
>   [ $1 = 0 ] && rm -f %{_sysconfdir}/bash_completion.d/%{name}

Marking that as %ghost would eliminate the need for this.  But you'd
still need to own the bash_completion.d dir (%ghost'd too if you like).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]