Re: initscripts package available for review/upload

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Sergey Okhapkin wrote:

> I see no reason to release a new version just to rename a file, I'd like to
> get some feedback from users first. Moreover, /etc/inittab is very easy and
> clear file, initscripts package provides a ready-to-use-for-all version of
> the file. That's why I want to make initscripts package available via setup
> ASAP.

Sergey, you just don't get it.  Filename collisions are a BIG deal, and 
will lead (have led) to major furballs on the main mailing list.  Your 
cavalier attitude about them -- vis a vis: you still advocated the 
premature uploading of sysvinit even AFTER it was pointed out that it 
conflicted with a pre-existing package -- my cygutils package.

What we REALLY need is a package linter, so these problems are flagged 
automatically.  But that'll be a while.

Here's the pattern:

1) you publish sysvinit-1.00.  The tarball explicitly contains 
/etc/inittab.  setup.exe records this file as "belonging" to sysvinit.

2) you publish initscripts-1.00, which ALSO contains /etc/inittab. 
Setup unpacks it and clobbers the original version (from sysvinit). 
setup now records /etc/inittab as belonging to initscripts (but it still 
thinks it ALSO belongs to sysvinit.  Setup doesn't yet have a 
comprehensive database to keep track of conflicts like this)

3) you publish a new version of sysvinit (-1.01 ?) for some other reason 
-- but while you're making the "important" change, you also remember to 
remove its copy of /etc/inittab.  Setup, when it installs the new 
tarball, does this:
  a) first, look in the database for sysvinit, and deletes all files 
from the original sysvinit tarball.  This includes /etc/inittab -- buh 
bye.  There goes the initscripts version; it's gone.
  b) then, setup unpacks the new sysvinit tarball.

End result: /etc/inittab is gone.

This also was the result of the premature uploading of sysvinit in the 
first place; anyone who installed sysvinit and THEN upgraded cygutils 
lost last.exe and utmpdump.exe.

What *SHOULD* have happened is that you waited until I had a chance to 
remove last.exe and utmpdump.exe from cygutils, and put that on 
sourceware.  Then, folks would have upgraded cygutils FIRST (removing 
last.exe and utmpdump.exe), and then installed sysvinit SECOND (thus 
regaining the "lost" files).  [As it happens, if cygutils were updated 
and sysvinit were installed during the SAME execution of setup.exe on a 
user's machine, then there will not be a problem either, because setup 
uninstalls all packages that are to be upgraded, and then installs any 
updated/new packages.]

Admittedly, this is difficult to coordinate when the packages in 
question are "owned" by different people -- even though I gave fair 
warning on the list that is would be a problem, and that I was acting 
very rapidly to make it a non-problem.

But it's much easier when both packages are owned by the same person -- 
you!  YOU have the power to prevent the scenario above, w.r.t. sysvinit 
and inittab!

YES, sometimes it IS important to release a new package when only a 
single file changes.  It's not like sysinit is a 5MB behemoth download 
like perl.  (Besides, you already have one change to make in sysvinit 
anyway -- the postinstall snippet I sent you.  This makes two.)

One other minor niggle:  sysvinit contains a number of section 8 
manpages for programs that are not included in the sysvinit package 
(shutdown, reboot, poweroff? halt?).  Should those manpages be moved 
into Corinna's shutdown package, or should Corinna's windows version of 
shutdown be absorbed into your sysvinit package?

But that's between you and Corinna.  If status quo w.r.t. those 
manpages, while confusing, is okay with you two, then I guess that's fine.

--Chuck