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

This is Interesting: Free IT Magazines  
Home > Archive > Debian Developers > October 2005 > Advices needed for moving {add|remove}-shell from passwd to debianutils





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

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

2005-10-01, 5:54 pm

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
time.

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..

--



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Peter Samuelson

2005-10-01, 8:48 pm


[Christian Perrier]
> 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).


passwd effectively is Essential because bash depends on it. So I'm
pretty sure you don't have to worry about it being removed.

Just coordinate two uploads to happen in the same dinstall cycle:

shadow 1:4.0.12-6 where passwd Depends: debianutils (>= 2.15)
debianutils 2.15 Conflicts and Replaces: passwd (<< 1:4.0.12-6)

I think the passwd versioned dep on debianutils will have to stay until
etch is released.

Peter

Steve Langasek

2005-10-01, 8:48 pm

On Sat, Oct 01, 2005 at 03:05:30PM +0200, Christian Perrier wrote:
> 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


> 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
> time.


Is that actually likely to happen? If this is coordinated, surely uploading
the new passwd and debianutils within a day of each other is as easy as
uploading shadow twice?

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


Yeah, that's one way to ensure the uploads are coordinated.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/

Frans Pop

2005-10-01, 8:48 pm

Peter Samuelson

2005-10-02, 2:50 am


[Frans Pop]
>
> Hmm. That will cover i386 I guess. What about other arches that are
> autobuilt? (Assuming of course that both maintainers upload for i386.)


Good point, might it be better to upload shadow first and get it
autobuilding everywhere, then debianutils? The one will be
uninstallable for a day or two, but having something uninstallable for
a day is quite normal for unstable.

Henrique de Moraes Holschuh

2005-10-02, 2:50 am

> > A simpler solution could be merging 3) and 5) in a single upload. Then
>
> Yeah, that's one way to ensure the uploads are coordinated.


BUT one should have the dependencies (and eventually build dependencies) in
there ANYWAY.

People often do partial upgrades, so keep the dependencies there. And the
buildds often screwup transitions if you don't clamp it in build
dependencies, so if it affects the build, clamp it with versioned build
dependencies and conflicts.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Christian Perrier

2005-10-02, 2:50 am

Short summary of answers....

Our plan seems correct. Some (Peter Samuelson, Steve Langasek) suggest
it is a bit overflated and synced uploads of fixed packages should be
enough.

However, Frans mentioned autobuilders which will not guarantee that
both packages will reach unstable at the same dinstall run for all
arches.

Of course, if uploaded at the same time, that should be OK but we have
to deal with Murphy's law: this is why I prefer keeping both packages
installable at all moments...even if it complicates the process.

So, up to now, no change to our plans..:-)

Peter Samuelson mentioned passwd being Essential because it depends on
passwd. This is actually right. However this dependency is just the
consequence of bash needing the add-shell and remove-shell
utilities...so, in the future, bash shouldn't depend on passwd
anymore.

Other contributors, please continue commenting...



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Peter Samuelson

2005-10-02, 7:50 am


[Christian Perrier]
> Peter Samuelson mentioned passwd being Essential because it depends
> on passwd. This is actually right. However this dependency is just
> the consequence of bash needing the add-shell and remove-shell
> utilities...so, in the future, bash shouldn't depend on passwd
> anymore.


Right, but the point is, *right now* both passwd and debianutils are
Essential. This should prevent either from being removed from a
running system - if debianutils Conflicts/Replaces an old passwd before
the new passwd is in the archive, dpkg should refuse to upgrade to it.

And, maybe I'm just dense, but your plan appears to have the same race
condition, for new installs.

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com