Hi Sean,
Sean Whitton wrote:
> Ping -- what do you think about this?
Thanks for the reminder. Was busy with other packages the last
weekend. (Mostly working on Python 2 to 3 migration stuff.)
> >> I'd appreciate if you could look over these changes and tell me if you
> >> agree (as we both should agree on at least the list of slave
> >> alternatives), have alternative suggestions or otherwise comments.
> >
> > I thought about the issue of the Xsession.d file and
> > /etc/default/unclutter, and concluded that it could stay in
> > src:unclutter only. My thought was that most contemporary users of
> > unclutter-xfixes will probably expect to have to start the program
> > themselves, e.g. in ~/.config/i3/config.
Hrm, if it should be a drop-in replacement, IMHO also the package
should behave the same.
> > Someone who *does* want to keep using the Xsession.d file with
> > unclutter-xfixes can just install both unclutter and unclutter-xfixes.
This sounds like a rather ugly "solution" to me.
> > Without your additional changes on top of my patch, that will just work
> > (I've tested it): the priority of the unclutter-xfixes link group is 20,
> > such that if you have both packages installed unclutter-xfixes
> > automatically occupied /usr/bin/unclutter (since someone who has
> > installed unclutter-xfixes very likely wants to use that in preference
> > to unclutter-classic) but the Xsession.d file still works.
> >
> > Does this make sense to you?
Yes.
> > > * /etc/default/unclutter and /etc/X11/Xsession.d/90unclutter could be
> > > implementation-independent files, but then they need to be shipped
> > > either by both packages (which causes a file conflict) or we create
> > > some unclutter-common packages with just the common files between
> > > both implementations.
> > >
> > > Looks like the least complex implementation to me, but is probably
> > > also the one with the most coordination effort between the
> > > maintainers of both packages. (I suggest to maintain such a package
> > > together in git so that either maintainer can easily upload fixes.)
> >
> > If we decide want to go this route, I'd suggest that src:unclutter adds
> > a new bin:unclutter-common. No need for a new source package.
Hmmm, 'kay. Would be currently my preferred way although this feels as
if I'd eliminate you from contributing to it. But since that
suggestion came from you and unclutter is on Salsa under /debian/ (aka
collab-maint), you're welcome to contribute there anyway.
Actually, if we make a third unclutter-common binary package,
independent of where it comes from, we could make unclutter and
unclutter-xfixes only recommend it, so the users could opt out of the
whole "automatically starting" infrastructure. This should also
accommodate a bit your expectation of not being automatically started
by default.
> I'd like to get src:unclutter-xfixes into NEW and it would be best to do
> that only after we've finished discussing src:unclutter.
Thanks for caring!
I'll try to continue working on unclutter this weekend.
I suggest that our both's uploads on this will first go to Debian
Experimental unless we were able to test how the package work
together.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
