This proposal concerns packages that need to have files owned by a
dynamically created user. Currently, Policy recommends use of
dpkg-statoverride in postinst to change the ownership to the dynamically
created user after the user has been created. This Policy proposal would
instead create the use
On Fri, Aug 01, 2003 at 02:05:02AM -0400, Joey Hess wrote:
> Andrew Suffield wrote:
> > Hold that thought. We hashed out a few ideas on IRC; more in a few
> > days. Meanwhile, let's assume it will be solved... anything else?
> I missed that discussion, but the obvious approach in fakeroot is user
>
On Mon, Aug 04, 2003 at 10:37:53PM -0500, Adam Heath wrote:
> On Tue, 5 Aug 2003, Herbert Xu wrote:
> > On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
> > > You're confusing pre-depends and essentialness.
> >
> > What about the case if adduser needs a new feature in useradd and
> > thu
On Tue, 5 Aug 2003, Herbert Xu wrote:
> On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
> >
> > > You also need to ensure that adduser and anything that it depends on to
> > > function are always available at all times just like libc6.
> >
> > You're confusing pre-depends and essential
On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
>
> > You also need to ensure that adduser and anything that it depends on to
> > function are always available at all times just like libc6.
>
> You're confusing pre-depends and essentialness.
What about the case if adduser needs a new
On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
> On Sat, 2 Aug 2003, Herbert Xu wrote:
> > A single pre-dependency is not enough. You will need to convert all
> > of adduser's dependencies into pre-dependencies, and probably most
> > of the things it depends on as well.
>
> No. addu
On Sat, 2 Aug 2003, Herbert Xu wrote:
> Adam Heath <[EMAIL PROTECTED]> wrote:
> >
> >> Objection. There is no way to create any user in preinst as the tool
> >> to do so is not in an essential package.
> >
> > This is what pre-depends are for.
>
> A single pre-dependency is not enough. You will
On Sun, Aug 03, 2003 at 11:49:43AM +0100, Julian Gilbey wrote:
> Then change the line in the postinst:
>
> + if [ "$1" = configure ]
> + then
> for i in /usr/bin/foo /usr/sbin/bar
> do
> - if ! dpkg-statoverride --list $i >/dev/null
> + if [ dpkg --compare-versions "$2" lt "2.3.4-
Jakob Bohm <[EMAIL PROTECTED]> writes:
>dictdOops, no dependency on adduser
dictd has depended on adduser since 1.7.1-1, which was uploaded 9
July 2002 .
Regards,
Bob
--
_
|_) _ |_Robert D. Hilliard<[EMAIL PROTECTED]>
|_) (_) |_) 1294 S.W. Seagull Way
On Mon, Aug 04, 2003 at 07:20:51AM +1000, Herbert Xu wrote:
> On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote:
> >
> > Also, careful examination of the adduser implementation in
> > woody indicates that the package really only needs its
> > dependencies to be unpacked, at least to add s
On Sun, Aug 03, 2003 at 07:05:44PM -0400, Joey Hess wrote:
> Jakob Bohm wrote:
> > Note that only a few packages will need these dependencies,
> > unlike libc6. Specifically, these packages will be needed by a
> > subset of the packages that currently Depends: adduser .
>
> You have to depend on
Jakob Bohm wrote:
> Note that only a few packages will need these dependencies,
> unlike libc6. Specifically, these packages will be needed by a
> subset of the packages that currently Depends: adduser .
You have to depend on adduser?
Oops.
Adjust your numers accordingly. :-)
--
see shy jo
On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote:
>
> Also, careful examination of the adduser implementation in
> woody indicates that the package really only needs its
> dependencies to be unpacked, at least to add system users and
> groups. The configure steps of adduser, passwd, and
On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote:
> On Sat, Aug 02, 2003 at 09:59:13AM +1000, Herbert Xu wrote:
> > A single pre-dependency is not enough. You will need to convert all
> > of adduser's dependencies into pre-dependencies, and probably most of
> > the things it depends on a
On Sat, Aug 02, 2003 at 09:59:13AM +1000, Herbert Xu wrote:
> Adam Heath <[EMAIL PROTECTED]> wrote:
> >
> >> Objection. There is no way to create any user in preinst as the tool
> >> to do so is not in an essential package.
> >
> > This is what pre-depends are for.
>
> A single pre-dependency is
On Sat, 02 Aug 2003 09:59:13 +1000, Herbert Xu <[EMAIL PROTECTED]> said:
> Adam Heath <[EMAIL PROTECTED]> wrote:
>>
>>> Objection. There is no way to create any user in preinst as the
>>> tool to do so is not in an essential package.
>>
>> This is what pre-depends are for.
> A single pre-depend
On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote:
> for i in /usr/bin/foo /usr/sbin/bar
> do
>if ! dpkg-statoverride --list $i >/dev/null
>then
> dpkg-statoverride --update --add sysuser root 4755 $i
>fi
> done
>
> The corresponding dp
Adam Heath <[EMAIL PROTECTED]> wrote:
>
>> Objection. There is no way to create any user in preinst as the tool
>> to do so is not in an essential package.
>
> This is what pre-depends are for.
A single pre-dependency is not enough. You will need to convert all
of adduser's dependencies into pr
On Fri, 1 Aug 2003, Herbert Xu wrote:
> Andrew Suffield <[EMAIL PROTECTED]> wrote:
> >
> > And appending this text to section 10.9:
> >
> >
> > If you want files in a package to be owned by a dynamically allocated
> > user or group, then you should create the user or group in preinst,
Andrew Suffield wrote:
> Hold that thought. We hashed out a few ideas on IRC; more in a few
> days. Meanwhile, let's assume it will be solved... anything else?
I missed that discussion, but the obvious approach in fakeroot is user
autovivification (to bottow a term from perl) on chown.
--
see sh
Andrew Suffield <[EMAIL PROTECTED]> wrote:
>
> And appending this text to section 10.9:
>
>
> If you want files in a package to be owned by a dynamically allocated
> user or group, then you should create the user or group in preinst, so
> that it is present when the package is unpack
On Thu, Jul 31, 2003 at 01:16:35PM -0500, Adam Heath wrote:
> However, perhaps having fakeroot divert adduser, and when adduser is then run
> under fakeroot, a fakeroot-specific version would be used, that would
> communicate with faked, would be better.
That's problematic too. You imply that buil
On Thu, Jul 31, 2003 at 06:39:38PM +0100, Colin Watson wrote:
> On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote:
> > So, let's break down what happens a bit:
> >
> > - dpkg unpacks the files, with their original permissions
> > - postinst creates a user
> > - postinst adds a sta
On Thu, 2003-07-31 at 10:39, Colin Watson wrote:
> On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote:
> > So, let's break down what happens a bit:
> >
> > - dpkg unpacks the files, with their original permissions
> > - postinst creates a user
> > - postinst adds a statoverride to
On Thu, 31 Jul 2003, Andrew Suffield wrote:
> Here's the current text of the latter part of section 10.9.1:
>
>
> Given the above, dpkg-statoverride is essentially a tool for system
> administrators and would not normally be needed in the maintainer
> scripts. There is one type of sit
On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote:
> So, let's break down what happens a bit:
>
> - dpkg unpacks the files, with their original permissions
> - postinst creates a user
> - postinst adds a statoverride to change the permissions
>
> The "problem" is that the user do
Package: debian-policy
Here's the current text of the latter part of section 10.9.1:
Given the above, dpkg-statoverride is essentially a tool for system
administrators and would not normally be needed in the maintainer
scripts. There is one type of situation, though, where calls to
d
27 matches
Mail list logo
