It's Huntin' Season
Russell Coker
> So, if you're going to NMU packages (and this applies to the porters
> who've been doing NMUs already too) please be *very* careful of the
> following things:
>
> * A maintainer upload is better than a non-maintainer upload.
> Merging stuff from an NMU takes time and care. If it's not
> necessary, why the maintainer to waste time doing that instead
> of fixing other bugs or adding new features? OTOH, an NMU is
> better than nothing.
There's one other thing. I suggest that people should make very sure that
they've done as much as possible for their own packages before trying to fix
someone else's!
Personally I'd be rather unhappy if someone with dozens of bugs that are more
than a year old with no activity starts NMUing my packages! Sure, if you've
got your own packages right and you're sure you've got the skills then you
can do NMUs, but if you haven't fixed your own packages then concentrate on
them first!
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Banck
> There's one other thing. I suggest that people should make very sure that
> they've done as much as possible for their own packages before trying to fix
> someone else's!
As a rule of thumb, I agree. But OTOH, we have to get the freeze
freezing, and if you keep people with bugs in their priority: optional
packages from participating, then this will not help much.
So, if somebody has the skill to NMU a base package that needs NMUing,
but only maintains lower priority packages with some open RC bugs, I
think he should go forth nevertheless.
Michael
--
-:- aj [a...@azure.humbug.org.au] has joined #debian-devel
<willy> oh, crap, 13 RC bugs against base?
Hamish Moffatt
> http://lintian.debian.org/reports/mHamish_Moffatt.html#aprsd
> http://lintian.debian.org/reports/mHamish_Moffatt.html#mtrack
Mostly out-of-date-standards-version (not actually a bug)
and link-to-undocumented-manpage. Only the two non-conffile
things are real bugs. Anyway thanks for the link, I'll
have a big cleanup.
I have a couple of package-has-a-duplicate-relation warnings.
How do I avoid that? If I need a particular version of a package,
and dpkg-shlibdeps also picks it up, I end up with duplication
depends.
> Anyone object to me filing serious bugs against the 200 or so packages
> on this page?
>
> http://lintian.debian.org/reports/Tfile-in-etc-not-marked-as-conffile.html
They look like real bugs to me - so go ahead (IMHO).
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Martin Michlmayr
> Anyone object to me filing serious bugs against the 200 or so packages
> on this page?
>
> http://lintian.debian.org/reports/Tfile-in-etc-not-marked-as-conffile.html
I object. First of all, these lintians reports are not up to date so
packages might have been fixed in the meantime. Secondaly, iirc the
lintian reports were made against testing so packages might be fixed
already in sid.
--
Martin Michlmayr
t...@cyrius.com
Anthony Towns
> * Malcolm Parsons <mal...@ivywell.screaming.net> [20020129 19:48]:
> > Anyone object to me filing serious bugs against the 200 or so packages
> > on this page?
> > http://lintian.debian.org/reports/Tfile-in-etc-not-marked-as-conffile.html
> I object.
Rather than a knee jerk objection, how about a patch to fix the problems
you're concerned about?
> First of all, these lintians reports are not up to date so
> packages might have been fixed in the meantime. Secondaly, iirc the
> lintian reports were made against testing so packages might be fixed
> already in sid.
For example, the lintian reports include the version number of the
package. It's a straightforward matter to check whether this matches
the current version of the package, or not.
For example:
ssh master
cd /org/lintian.debian.org/laboratory/source
for a in *; do (cd $a && echo ${a}_*.tar.gz) | head -1; done |
sed 's/\.\(orig\.\)\?tar\.gz$//' |
tr '_' ' ' >~/lintianvers.txt
Putting blocks in the way of improving Debian is the exact *opposite*
of what we're all here for.
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
The daffodils are coming. Are you?
linux.conf.au, February 2002, Brisbane, Australia
--- http://linux.conf.au/
Gustavo Noronha Silva
Anthony Towns <a...@azure.humbug.org.au> wrote:
> On Wed, Jan 30, 2002 at 12:55:58PM +0100, Martin Michlmayr wrote:
> > * Anthony Towns <a...@azure.humbug.org.au> [20020130 20:23]:
> > > Putting blocks in the way of improving Debian is the exact *opposite*
> > > of what we're all here for.
> > I wasn't trying to block him from improving Debian but from mass filing
> > serious bugs on packages which might have been fixed already. We've
> > seen too many mass filings which didn't improve Debian at all; rather,
> > they blocked maintainers from doing their work.
> > If he checks the versions, I'm of course happy with this.
>
> Then help him do so. Don't just find problems, find solutions too.
/me notices that this freeze is stressing everyone....
come on people... you both are always doing lots for Debian and you
should not be targets for each other
my suggestion is to add this stuff to the QA's TODO list and let someone
pick it up... or shoot the maintainers who are uploading packages without
checking their packages with latest lintian... those should be the
targets
[]s!
--
Gustavo Noronha Silva - kov <http://www.metainfo.org/kov>
*---------* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
| .''`. | Debian GNU/Linux: <http://www.debian.org> |
| : :' : + Debian BR.......: <http://debian-br.cipsga.org.br>+
| `. `'` + Q: "Why did the chicken cross the road?" +
| `- | A: "Upstream's decision." -- hmh |
*---------* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
Malcolm Parsons
> my suggestion is to add this stuff to the QA's TODO list and let someone
> pick it up... or shoot the maintainers who are uploading packages without
> checking their packages with latest lintian... those should be the
> targets
It's a fairly recent lintian change, so the error probably wouldn't have
been given the last time the package was uploaded.
Anthony Towns
> On Wed, Jan 30, 2002 at 11:58:13PM +1000, Anthony Towns wrote:
> > On Wed, Jan 30, 2002 at 12:55:58PM +0100, Martin Michlmayr wrote:
> > > * Anthony Towns <a...@azure.humbug.org.au> [20020130 20:23]:
> > > > Putting blocks in the way of improving Debian is the exact *opposite*
> > > > of what we're all here for.
> > > I wasn't trying to block him from improving Debian but from mass filing
> > > serious bugs on packages which might have been fixed already. We've
> > > seen too many mass filings which didn't improve Debian at all; rather,
> > > they blocked maintainers from doing their work.
> > > If he checks the versions, I'm of course happy with this.
> > Then help him do so. Don't just find problems, find solutions too.
> either. Don't reject problems just because they don't have solutions
> attached. (And then we wonder why so often people complain about
> things but don't file bugs...)
I'm not sure what relevance you think this has. There was a reason I
posted some code to make it fairly easy to work out which packages can
have bugs filed on them based on the out-of-date lintian reports.
Not attaching solutions in some cases is just a fact of life, sometimes
it's much harder to find the solution than to define the problem. In
this case, it's absolutely trivial to find the solution, and there's
hence no excuse for not just going ahead and doing it so we can get on
with our lives, and not have to worry about it anymore.
For reference, the rest of the solution is:
ssh auric
zcat /org/ftp.debian.org/ftp/dists/sid/main/source/Sources.gz |
awk '/^Package: / {P=$2} /^Version: / {print P, $2}' |
sort > real_vers.txt
scp master:~/lintian_vers.txt .
scp auric:~/real_vers.txt .
comm -12 lintian_vers.txt real_vers.txt >usepkgs.txt
comm -23 lintian_vers.txt real_vers.txt >excludepkgs.txt
If you really, truly want to improve things for users, worry more about
coding solutions to problems than bickering on -devel. Seriously.
Peter S Galbraith
> Anyone object to me filing serious bugs against the 200 or so packages
> on this page?
>
> http://lintian.debian.org/reports/Tfile-in-etc-not-marked-as-conffile.html
>
> I'll be ignoring all the README files.
I replied:
> Please ignore all the Emacs ones too.
Malcolm Parsons <mal...@ivywell.screaming.net> wrote:
> No.
>
> If the .el files are not supposed to be edited they should not be in
> /etc
Nice reaction.
We don't have a choice; that's where they go. Please read Emacs policy.
That's where we put files that Emacs reads on startup to setup add-on
packages (e.g. /etc/emacs/site-start.d/).
We discussed this on debian-emacsen last year. See:
http://lists.debian.org/debian-emacsen/2001/debian-emacsen-200102/msg00012.html
A lot of maintainers don't mark the files there as confiles because they
don't expect them to be edited. If you want a second startup.d
directory outside of /etc for this purpose, change Emacs policy and
patch the added started code in all Emacsen. Then we can move our code
out.
But at least discuss this on debian-emacsen instead of spontanously
submitting serious bug against packages for something that has been the
custom to do.
It's possible that some packages have moved to setting it as conffile
simply because debhelper might be use to install the Emacs files, and
when DH_COMPAT is set to 3 they are made conffiles automatically.
(I noticed that the mh-e package I recently uploaded has marked as a
conffile precisely for this reason, while my older packages don't.)
How about it, debian-emacsen collegues, is it time to set (or follow)
policy and mark them _all_ as conffiles? Do we have clear example of
where this would be a nuisance?
Thanks,
Peter
Adam Heath
> > If the .el files are not supposed to be edited they should not be in
> > /etc
>
> Nice reaction.
And a correct one. Read Debian Policy, which comes before any
sub-policies(emacs, java, perl, python, etc).
> We don't have a choice; that's where they go. Please read Emacs policy.
> That's where we put files that Emacs reads on startup to setup add-on
> packages (e.g. /etc/emacs/site-start.d/).
Fine. So that's where they go. But you must still follow Debian Policy about
files in /etc.
> We discussed this on debian-emacsen last year. See:
> http://lists.debian.org/debian-emacsen/2001/debian-emacsen-200102/msg00012.html
So? Does that mean that what was said then can't be changed?
> A lot of maintainers don't mark the files there as confiles because they
> don't expect them to be edited. If you want a second startup.d
> directory outside of /etc for this purpose, change Emacs policy and
> patch the added started code in all Emacsen. Then we can move our code
> out.
Files in /etc are to be marked conffiles. Period. End of story. Have a nice
day.
In other words, just because the emacs policy doesn't say they should be
marked conffiles, doesn't mean they shouldn't be marked conffiles. The emacs
policy is in addition to existing Debian Policy. You can't follow the former
without following the latter.
> But at least discuss this on debian-emacsen instead of spontanously
> submitting serious bug against packages for something that has been the
> custom to do.
It may be the custom. That doesn't mean it is correct.
> How about it, debian-emacsen collegues, is it time to set (or follow)
> policy and mark them _all_ as conffiles? Do we have clear example of
> where this would be a nuisance?
It's a bug, plain and simple. And RC(serious) at that.
Manoj Srivastava
Peter> How about it, debian-emacsen collegues, is it time to set (or follow)
Peter> policy and mark them _all_ as conffiles? Do we have clear example of
Peter> where this would be a nuisance?
I was going to say we should mark them as conffiles, for
consistencies sake, if for no other reason, when I noticed an
interesting fact: none of my emacs packages actually ships with a
file in in /etc, and I have checked: gnus, vm, and psgml.
If I don't ship files in /etc, I can't really mark them as
conffiles, now, can I?
However, if files are shipped in /etc, they _have_ to be
marked as conffiles, I think.
manoj
--
You ain't learning nothing when you're talking.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Peter S Galbraith
> On Wed, 30 Jan 2002, Peter S Galbraith wrote:
>
> > > If the .el files are not supposed to be edited they should not be in
> > > /etc
> >
> > Nice reaction.
>
> And a correct one. Read Debian Policy, which comes before any
> sub-policies(emacs, java, perl, python, etc).
I was more referring to the plain "No.".
It's sucks that everybody is so confrontational all the time.
> > We don't have a choice; that's where they go. Please read Emacs policy.
> > That's where we put files that Emacs reads on startup to setup add-on
> > packages (e.g. /etc/emacs/site-start.d/).
>
> Fine. So that's where they go. But you must still follow Debian
> Policy about files in /etc.
Which is why I was asking if we had cases where that would be bad.
Usually you place a file under /etc because it's a config file. These
emacs files are there because that's where Emacs sets up. Yes, I know
what you just said, but try to see the reason things have been like this
for years.
> > We discussed this on debian-emacsen last year. See:
> > http://lists.debian.org/debian-emacsen/2001/debian-emacsen-200102/msg00012.
> html
>
> So? Does that mean that what was said then can't be changed?
So? When did I say otherwise? In fact, I later ask if we should.
Quit being so confrontational for no reason please.
> > A lot of maintainers don't mark the files there as confiles because they
> > don't expect them to be edited. If you want a second startup.d
> > directory outside of /etc for this purpose, change Emacs policy and
> > patch the added started code in all Emacsen. Then we can move our code
> > out.
>
> Files in /etc are to be marked conffiles. Period. End of story.
> Have a nice day.
What's the relation with what I said in the above paragraph. I don't
see it. Quit being so confrontational for no reason please.
> In other words, just because the emacs policy doesn't say they should be
> marked conffiles, doesn't mean they shouldn't be marked conffiles. The emacs
> policy is in addition to existing Debian Policy. You can't follow the former
> without following the latter.
You said that already.
> > But at least discuss this on debian-emacsen instead of spontanously
> > submitting serious bug against packages for something that has been the
> > custom to do.
>
> It may be the custom. That doesn't mean it is correct.
You said that already.
> > How about it, debian-emacsen collegues, is it time to set (or follow)
> > policy and mark them _all_ as conffiles? Do we have clear example of
> > where this would be a nuisance?
>
> It's a bug, plain and simple. And RC(serious) at that.
Oh man. It's great talking to you.
Now, on to the problem at hand.
- Do we have files under /etc/emacs that really shouldn't be conffiles?
- If so, can the bulk of them be moved out of /etc/emacs and loaded by
smaller conffiles under /etc/emacs? Then all /etc/emacs files could
be conffiles (and we should spell it out in emacs-policy).
I don't think any of my /etc/emacs setup files would benefit from being
conffiles, but none would be hurt either (or hurt users). If they have
no need to edit them, they probably won't. And then they won't get
useless prompts on upgrades when I add stuff to them. I'll just do that
with my packages.
Peter
Peter S Galbraith
> >>"Peter" == Peter S Galbraith <p.gal...@globetrotter.net> writes:
>
> Peter> How about it, debian-emacsen collegues, is it time to set (or follow)
> Peter> policy and mark them _all_ as conffiles? Do we have clear example of
> Peter> where this would be a nuisance?
>
> I was going to say we should mark them as conffiles, for
> consistencies sake, if for no other reason,
I agree.
> when I noticed an
> interesting fact: none of my emacs packages actually ships with a
> file in in /etc, and I have checked: gnus, vm, and psgml.
But they ship the empty directories. ;-)
So you don't setup autoloads or auto-mode-alist entries?
I guess the load-path add-on of subdirectories is done by modern emacsen
anyway, but are they at the right place? If so, perhaps we should
discontinue the habit of adding anything to the load-path.
> However, if files are shipped in /etc, they _have_ to be
> marked as conffiles, I think.
Do we need another non-conffile directory to put startup files?
I don't. Does anyone else?
Adam Heath
> I guess I am violating the spirit, though not the letter, of
> policy by not testing to see if the previous startup script has been
> modified by the user. Hmm. Durnit.
Please read policy section 11.7.1, 11.7.2, and 11.7.3. If you obliterate the
admins changes, then you are in violation of policy(11.7.3 lists it as a
'must').
Malcolm Parsons
> Malcolm Parsons <mal...@ivywell.screaming.net> wrote:
> > If the .el files are not supposed to be edited they should not be in
> > /etc
>
> http://lists.debian.org/debian-emacsen/2001/debian-emacsen-200102/msg00012.html
That thread includes an example where it is useful to edit a .el file,
so it should be a conffile.
> A lot of maintainers don't mark the files there as confiles because they
> don't expect them to be edited.
If you don't expect them to be edited then having them as conffiles
will not cause any problems, as dpkg does not prompt unless they have
been changed. You cannot predict which .el files I will not want to
change, so you must mark all of them as conffiles.
> How about it, debian-emacsen collegues, is it time to set (or follow)
> policy and mark them _all_ as conffiles? Do we have clear example of
> where this would be a nuisance?
Yes. No.
Peter S Galbraith
> On Wed, Jan 30, 2002 at 08:41:38PM -0500, Peter S Galbraith wrote:
> > A lot of maintainers don't mark the files there as confiles because they
> > don't expect them to be edited.
>
> If you don't expect them to be edited then having them as conffiles
> will not cause any problems, as dpkg does not prompt unless they have
> been changed. You cannot predict which .el files I will not want to
> change, so you must mark all of them as conffiles.
(As an aside, yes I can predict that you won't want to edit the file
that I didn't mark as a conffile, at least to the same degree that you
won't want to edit other elisp files in the package. Why would you want
to break proper configuration?)
There is a caveat to now making it a conffile. At the upgrade that
marks the passage of non-conffile to conffile, we get the dreaded
prompt:
Setting up gri-html-doc (2.8.6-1) ...
Configuration file `/etc/emacs/site-start.d/50gri-html-doc.el'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** 50gri-html-doc.el (Y/I/N/O/D/Z) [default=N] ?
So every user will get one prompt for each file we migrate. :-(
Peter
Wilmer van der Gaast
> If the .el files are not supposed to be edited they should not be in
> /etc
>
--
+-------- .''`. - -- ---+ + - -- --- ---- ----- ------+
| lintux : :' : lintux.cx | | Unix and CGI @ IOI/NIO(Dutch)at |
| at `. `~' debian.org | | www.lintux.cx/ www.algoritme.nl |
+--- -- - ` ---------------+ +------ ----- ---- --- -- - +
David N. Welton
> I do not have any helper scripts installed on my machines. I
> hand craft my rules files.
>
> manoj
Back in the good old days, when there were only 1's and 0's, and even
1's were a scarce resource, Manoj wrote a whole install system with
only 0's. It was quite impressive.
With apologies to Dilbert,
--
David N. Welton
Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
Hamish Moffatt
> Malcolm Par...@lists.debian-devel@Wed, 30 Jan 2002 22:35:21 +0000:
> > If the .el files are not supposed to be edited they should not be in
> > /etc
> >
> What about /etc/init.d/ then?
They may be edited by the local admin and there are good reasons
to do so at times.
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Nicolas Boullis
On Thu, Jan 31, 2002 at 09:17:06PM -0500, Peter S Galbraith wrote:
>
> There is a caveat to now making it a conffile. At the upgrade that
> marks the passage of non-conffile to conffile, we get the dreaded
> prompt:
>
> Setting up gri-html-doc (2.8.6-1) ...
>
> Configuration file `/etc/emacs/site-start.d/50gri-html-doc.el'
> ==> File on system created by you or by a script.
> ==> File also in package provided by package maintainer.
> What would you like to do about it ? Your options are:
> Y or I : install the package maintainer's version
> N or O : keep your currently-installed version
> D : show the differences between the versions
> Z : background this process to examine the situation
> The default action is to keep your current version.
> *** 50gri-html-doc.el (Y/I/N/O/D/Z) [default=N] ?
>
> So every user will get one prompt for each file we migrate. :-(
Can't you test in preinst if this file is the one you shipped in the
previous version ov the package ?
If it is the same, you can delete (or better move) it in preinst,so
config won't complain...
And if it's not the same, you have the question, but you would also have
had it with conffiles...
Please feel free to flame me if my suggestion is stupid.
Regards,
Nicolas
Peter S Galbraith
> On Fri, Feb 01, 2002 at 10:55:53PM +0100, Nicolas Boullis wrote:
> >
> > Can't you test in preinst if this file is the one you shipped in the
> > previous version ov the package ?
>
> i suppose you could, but you'd have to have a list of each md5sum from
> _each_ previous incarnation, since we don't know before hand the
> previous version tht is being upgraded from.
>
> > Please feel free to flame me if my suggestion is stupid.
>
> if you ``optimise'' for the common case (ie: say going from 3.14-5 to
> 3.14-59) and check that md5sum _only_, then you can prevent a good
> percentage of people from getting asked.
>
> not a bad idea, if you can determine what a good percentage (20%? 80%?)
> of target upgrade paths would be, and plan accordingly.
Could do it using the potato version as the one I check for.
Thanks! I'll consider doing this.
Peter
Nicolas Boullis
> Could do it using the potato version as the one I check for.
I think you should better first check for 2/3 version: the potato
version, the latest sid version, and the latest woody version (if it is
different).
Later, and before woody's release, you may remove the test for the sid
and woody version.
Hence, people who keep a woody/sid system up to date won't either have
the question...
What do you think of this suggestion? Would it be too much to test 2/3
versions ?
Regards,
Nicolas
Manoj Srivastava
Manoj> If you look at the script I posted, the user is not asked any
Manoj> questions if the file on the system is the same file that is
Manoj> currently being shipped. In the general case, I think this is good
Manoj> enough; if one cares, one can special case the md5sum of the last
Manoj> non-conffile one shipped and check that, but I hate special cases.
AAArrrgh. I hate following up to myself. I am going to go away
from my machine and do something else. Like see LOTR again.
On further inspection, one does not need special case code in
the script: you just need to ship the old md5sum file in your package
(no harm in making the md5sum file a part of your package). In that
case, the conffile handling is done right.
manoj
--
Nezvannyi gost'--khuzhe tatarina. [An uninvited guest is worse than
the Mongol invasion] Russian proverb
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Nicolas Boullis
On Fri, Feb 01, 2002 at 04:53:24PM -0600, Manoj Srivastava wrote:
> If you look at the script I posted, the user is not asked any
> questions if the file on the system is the same file that is
> currently being shipped. In the general case, I think this is good
> enough; if one cares, one can special case the md5sum of the last
> non-conffile one shipped and check that, but I hate special cases.
I agree that special cases should generally be avoided. But in such a
situation, these special cases help our users to upgrade smoothly.
Hence, I think that, in such a situation, special cases are a
Good Thing (tm).
Regards,
Nicolas
Peter S Galbraith
> >>"Nicolas" == Nicolas Boullis <Boullis...@libertysurf.fr> writes:
>
> Nicolas> Can't you test in preinst if this file is the one you shipped in th
> e
> Nicolas> previous version ov the package ?
>
> You may not need to do it in preinst, since these files are
> created/updated in the postinst (which is the reason they can't be
> marked as conffiles in the first place).
Mime was included in the package, but wasn't marked.
> If you look at the script I posted, the user is not asked any
> questions if the file on the system is the same file that is
> currently being shipped. In the general case, I think this is good
> enough; if one cares, one can special case the md5sum of the last
> non-conffile one shipped and check that, but I hate special cases.
I'll look at your script.
Thanks,
Peter
Manoj Srivastava
John> On Fri, Feb 01, 2002 at 05:07:26PM -0600, Manoj Srivastava wrote:
>>
>> On further inspection, one does not need special case code in
>> the script: you just need to ship the old md5sum file in your package
John> looking at your script, it did not seem to be the case, but i will ask
John> anyway:
John> does it support a multiple set of potential md5sums? if no, then it's
John> better than nothing, and i do not see a pressing need to add that.
No, it does not. I meant this script to be a general purpose
conffile provider, with some recovery provisions for transitioning
from a broken package that did not preserve configuration files. I
did not mean it to be a script that does not ask a singlke question
despite trying to recover from an extraordinary situation.
manoj
--
Oblivion together does not frighten me, beloved. Thalassa (in Anne
Mulhall's body), "Return to Tomorrow", stardate 4770.3.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
Nicolas> Hi!
Nicolas> On Fri, Feb 01, 2002 at 04:53:24PM -0600, Manoj Srivastava wrote:
>> If you look at the script I posted, the user is not asked any
>> questions if the file on the system is the same file that is
>> currently being shipped. In the general case, I think this is good
>> enough; if one cares, one can special case the md5sum of the last
>> non-conffile one shipped and check that, but I hate special cases.
Nicolas> I agree that special cases should generally be avoided. But in such a
Nicolas> situation, these special cases help our users to upgrade smoothly.
Nicolas> Hence, I think that, in such a situation, special cases are a
Nicolas> Good Thing (tm).
FUD. Asking a question to recover from a broken package does
not mean an unsmooth upgrade. Indeed, merely treating the transition
from a package theat over writes user changes to one that preserves
them, while noticing that the users current file is different from
the one shipped, and asking them what to do about it, is a _smoooth_
transition.
All your check eliminate is a question before replacing the
config file. Allowing people to specify multiple files that may
contain old md5sums is feasible (use a dir instead of a file, and
check every file in that directory), but the added complexity (and
thus potential for error) is not worth the reward (which is a
avoiding a question during postinst)
Offer me reasons why I may be in error, and I'll implement any
number of historical md5sums that'l be checked in addition to the
dynamic md5sum of the ``last'' released version of the config file.
manoj
--
He who has imagination without learning has wings but no feet.
Manoj Srivastava
Adam> On Fri, 1 Feb 2002, Manoj Srivastava wrote:
>> On further inspection, one does not need special case code in
>> the script: you just need to ship the old md5sum file in your package
>> (no harm in making the md5sum file a part of your package). In that
>> case, the conffile handling is done right.
Adam> How would that work, exactly? I would assume the md5sum would
Adam> be generated at package build time. And when the new package
Adam> is built, the md5sum of the 'new' file would be stored.
Perhaps it is not as striaght forward as that.
Adam> However, for conffile-like handling, you need the md5sum of the
Adam> conffile at the time the package was 'last' installed.
That is what I meant. But then future upgrades would be messed
up, since you can't just remove the file from the package, and in the
future, your static file would override the file on the target machine.
Adam> Doing it as you suggest above would not work.
Quite.
manoj
--
Nothing is but what is not.