hey Christoph,
On Wed, Jul 23, 2003 at 03:27:47PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> > libacl1 and libattr1 to base and required status. (Or demote coreutils
>
> Oh and btw, the depency on libattr1 is probably a bug. Since glibc 2.3
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> (Please CC: me, I no longer track debian-devel)
>
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
> will indicate whether a file has an
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
I think this would be a good thing.
> will indicate whether a file has an acl.) Doing th
On Wed, Jul 23, 2003 at 09:43:17AM -0400, Clint Adams wrote:
How about selinux support?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193328
Mike Stone
On Wed, Jul 23, 2003 at 03:05:34PM +0200, Matthias Urlichs wrote:
What'd be the problem with a package "coreutils-acl" that just Conflicts:
and Provides: coreutils?
I'd worry about the fragility of such a system in the face of upgrades,
the inability for a coreutils-acl to do a versioned provides:
On Jul 23, Michael Stone <[EMAIL PROTECTED]> wrote:
>I am contemplating the upload of a version of coreutils that will have
>support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
Please do.
--
ciao, |
Marco | [963 dih6i3GB682fA]
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> A demo package is available at people.d.o/~mstone/
Out of curiosity, is there a particular reason why acl support is not
integrated upstream?
--
- mdz
On Wed, Jul 23, 2003 at 03:05:35PM +0200, Matthias Urlichs wrote:
> Hi, Michael Stone wrote:
> > Another possibility would be an optional coreutils-acl package or
> > somesuch, but I don't particularly like the idea of diversions or
> > alternatives or complex dependency structures for ls et al.
>
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> (Please CC: me, I no longer track debian-devel)
You should move debian-devel from "subscribe" to "lists" to automatize
this.
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv
> (Please CC: me, I no longer track debian-devel)
Your M-F-T is broken.
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
How about selinux support?
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> libacl1 and libattr1 to base and required status. (Or demote coreutils
Oh and btw, the depency on libattr1 is probably a bug. Since glibc 2.3
we have the xattr syscalls in libc (see /usr/include/sys/xattr.h)
On Wed, 23 Jul 2003, Michael Stone wrote:
> (Please CC: me, I no longer track debian-devel)
>
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
Yay! Please do so!
> Another possibility would be an opt
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> I don't know whether kernels other than linux support acl's, so this may
> not affect the freebsd or hurd ports.
FreeBSD supports ACLs but they don't have a libacl - their support
for Posix1003.1e is in libc.
Hi, Michael Stone wrote:
> Another possibility would be an optional coreutils-acl package or
> somesuch, but I don't particularly like the idea of diversions or
> alternatives or complex dependency structures for ls et al.
What'd be the problem with a package "coreutils-acl" that just Conflicts:
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote:
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
> will indicate whether a file has an acl.) Doing this would promote
> libacl1 and libatt
* Michael Stone ([EMAIL PROTECTED]) wrote:
> to optional, but that would probably break something.) Thus, I am
> soliciting input about whether this is something people would like to
> see. The advantage is better support for acl's in debian (which will be
I'd definitely like to see it. I think t
(Please CC: me, I no longer track debian-devel)
I am contemplating the upload of a version of coreutils that will have
support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
will indicate whether a file has an acl.) Doing this would promote
libacl1 and libattr1 to base and required
17 matches
Mail list logo