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

Bug#883711: marked as done (pkgsel: should running updatedb really be the default?)

Your message dated Fri, 8 Dec 2017 09:43:57 +0100
with message-id <20171208084357.nh3uiue3czdd6rnc@mraw.org>
and subject line Re: Bug#883711: pkgsel: should running updatedb really be the default?
has caused the Debian Bug report #883711,
regarding pkgsel: should running updatedb really be the default?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
883711: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883711
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: pkgsel
Version: 0.46
Severity: important

Hi,

This commit looks like something that should be been discussed, rather than
something I get to discover while preparing the release announcement:
| commit fdc3d5a6cf5d2af0ca67494321faf4088170362a
| Author: Raphaël Hertzog <hertzog@debian.org>
| Date:   Fri Sep 15 12:16:37 2017 +0200
| 
|     Run updatedb by default when a locate implementation has been installed
|     
|     This can be disabled with the pkgsel/updatedb preseed.
|     
|     This change has been taken from Ubuntu.

Especially with such a description:
| Description: for internal use; can be preseeded
|  If mlocate is installed, update its database after installing packages.
|  This is time-consuming, so you may wish to set this to false to disable it.


If you're concerned about users expecting to be able to run *locate without
waiting for the cron.daily entry, I think it'd be better to have
implementations mention that the DB is empty and how to initialize it
instead.

Currently, locate returns nothing with an empty DB, while mlocate's error
message could be improved:
| locate: can not stat () `/var/lib/mlocate/mlocate.db': No such file or directory

Also, we seem to have a dlocate implementation too.


I might flip the default to false for the next release, as I don't see why
every user should pay this price for no obvious gain.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

--- End Message ---
--- Begin Message --- 
Hi,

Raphael Hertzog <hertzog@debian.org> (2017-12-08):
> Most of the time when I hear from you, it's for a complaint. You might
> not realize, but your mails are very often passive aggressive and
> (from first-hand comments I got) they are driving away some
> contributors.

Well, I opened this bug report to keep track of a change in default
behaviour, to make sure people reading the release announcement for D-I
Buster Alpha 2 would have a pointer to an actual discussion about this
change; which never happened in the first place. I'm not sure it is to be
considered a complaint or passive aggressive though. That's standard
procedure.

It's been repeated over and over again: developers are supposed to discuss
changes impacting the debian installer on the debian-boot@ mailing list, or
in a bug report. Some contributors have not followed that, repeatedly, and
I've on occasion not be the nicest person in the world as a consequence,
e.g. while dealing with the resulting breakages. Sure, I could have been
more patient, etc.; no, I'm not perfect. But there are two sides to every
story.

> It would be so much better if you could just start by thanking people for
> the work they put into Debian. Something like this:
> 
> « Thanks for your contribution, but I would like to have some discussion
> about this feature that you committed. I'm not convinced that ...
> because .... What do people think ? »

Again, the “what do people think?” part should have been the first step.

> You tend to write mails that bring to our attention how we did annoy you
> in some way. While you might be really annoyed, none of us are doing
> anything to annoy you voluntarily.

As explained in my first paragraph, that's not the intent.

> [ Sorry for this small digression, I don't know if you ever heard such
> a complaint but I found it important to let you know my feelings. I
> hope it can help you become a better d-i release manager. If not,
> sorry to have annoyed you even more. ]

[ I'm fine with hearing about your feelings. I'm not sure I can do much
about people not following guidelines in the first place, and then
finding it offensive to see bug reports get opened afterwards to try and
figure out whether to keep such changes enabled. ]

> > If you're concerned about users expecting to be able to run *locate
> > without waiting for the cron.daily entry, I think it'd be better to
> > have implementations mention that the DB is empty and how to
> > initialize it instead.
> 
> That's certainly a possible improvement. Not one I'm going to pursue
> though. I was working on pkgsel and took the opportunity to review
> and merge useful Ubuntu changes. This one looked like fine... in
> particular because I remembered to have been hit by this in the past.
> 
> > I might flip the default to false for the next release, as I don't
> > see why every user should pay this price for no obvious gain.
> 
> All locate implementations that we have are optional, so they are not
> installed by default. They are also not part of any standard desktop
> task.
> 
> Thus it's not a price that every user will pay. Only those that
> install those packages.
> 
> IMO changing the default value means the entire feature is useless,
> you might as well revert the commit in that case. I will not be
> offended by such a revert.

Ah, I hadn't realized how little *locate are depended on, especially by
desktop tasks, thanks. I'm guessing the existence of the preseed setting
is a bit strange then, if users getting those packages did actually ask
for it…

Anyway, let's keep that change as it is.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: