initscripts package available for review/upload
Charles Wilson
cwilson@ece.gatech.edu
Wed Nov 13 19:03:00 GMT 2002
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
More information about the Cygwin-apps
mailing list