Hello Axel, On Sun 01 Sep 2019 at 08:54PM +02, Axel Beckert wrote:
> Sean Whitton wrote: >> I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it >> to DELAYED/15. Please feel free to tell me if I should delay it longer. > > Yes, please remove it completely. It is incomplete and has unsolved > issues which might be even harder to fix properly afterwards if the > upload succeeds. Done, quite gladly. I decide whether to NMU based on activity in the bugs to be closed by the NMU, not on how active a maintainer is in general, since people who are active often don't have time for all of their packages. Anyway, I hope that no annoyance was generated. > I'll try to upload unclutter 8-22 (to experimental) before that NMU > passes throught, but for that, I need your feedback first: > > Please check the master branch under > https://salsa.debian.org/debian/unclutter and especially the commits I > made after applying your NMU patch minus the unnecessary NMU stuff: > > https://salsa.debian.org/debian/unclutter/commits/master > > Main points: > > * Make /etc/X11/Xsession.d/90unclutter a slave alternative, too. > * Rename /etc/default/unclutter to /etc/default/unclutter-classic. > * Make debian/unclutter.install executable. (Might have been lost when > you generated your patch as it clearly FTBFS else.) Yeah, nmudiffs can't record mode changes. It was executable in the source package I uploaded, though. > 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. I was certainly surprised when I first installed unclutter, rebooted for whatever reason and discovered it had started itself. Someone who *does* want to keep using the Xsession.d file with unclutter-xfixes can just install both unclutter and unclutter-xfixes. 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? I'm certainly not wedded to the idea, but I'd like to hear your opinion about it. > Open issues and why I haven't uploaded the current state to > experimental yet: > > * In the current setup, /etc/default/unclutter might need to be a > slave alternative, too. Not sure, though. Thoughts on this are > welcome! > > * /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. -- Sean Whitton
signature.asc
Description: PGP signature
