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

Advices needed for moving {add|remove}-shell from passwd to debianutils

The bugs #208514, #268656, #269573, #29317 all finally suggest moving
add-shell and remove-shell out of the passwd package.

These utilities are use to "register" shells in /etc/shells and they
obviously do no belong to the passwd package. 

Having them in passwd enforces shells to depend on it just because
they need the utilities to register shells.

So, moving them out of passwd finally seems logical and was discussed
with Clint Adams, maintainer of debianutils.

So Clint and us (shadow maintainers) have to deal with the transition
and make it as smooth as possible. We discussed the issue yesterday on
#shadow on freenode. However, the conclusion we draw probably need
some peer review. See #269573 for the whole discussion.

The goal is having a system which always has the two utilities...and
of course avoid the removal of passwd (debianutils is Essential while
passwd isn't).

The plan we draw is the following:

1) shadow package maintainers upload passwd which 
   "Depends: debianutils (<= 2.14.3)"
   this version *still* includes the utilities   

2) we warn Clint

3) He uploads debianutils 2.15 with the utilities

4) He warns us..:-)

5) We upload passwd *without* the utilities and 
   "Depends: debianutils (>= 2.15)"

6) we might need to later warn maintainers of shell packages which
   maybe depend on passwd just because they need the utilities

The purpose of 1) is to avoid the removal of passwd during new systems
installs between 3) and 5) in case both do not happen at the same

A simpler solution could be merging 3) and 5) in a single upload. Then
the "Depends" in 1) would not be needed.

Are there any comments about this?

I must admit I'm not familiar with such transitions so I humbly
request you folks to accept apologies if something above is stupid. My
knowledge of the subtleties of package interdependencies is not that
deep....even after reading the DR and the Policy...especially when it
comes at Essential packages.

In short, don't flame us, pals..:)


Reply to: