[arch-dev-public] nilfs-utils moving in core
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd. Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community. What do you think? Is it worth adding it? It must be in base group? -- Ionuț
Am 07.12.2010 14:40, schrieb Ionuț Bîru:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
That is not true. Packages don't have to be in core to be included in the installation environment.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
How many people use nilfs? I doubt very many. If you want to add another package to your list that nobody will sign off on, I don't object (even xfsutils and jfsutils rarely get signoffs, and those are popular file systems compared to nilfs).
On Tue, 07 Dec 2010 14:45:45 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 07.12.2010 14:40, schrieb Ionuț Bîru:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
That is not true. Packages don't have to be in core to be included in the installation environment.
We (or at least I) meant: including the packages in the included core repo on core images. So that if people install their system on a nilfs filesystem, they can install the nilfs-utils package too. I don't think we want situations where people use a core image, install nilfs, but aif can't install nilfs-utils. On the other hand, I just noticed dosfstools is in extra, whereas aif allows you to install on vfat. This confuses me. Isn't the general rule that if you can install on a foo-filesystem, you should install foo-utils as well? so that at least your system doesn't break when it needs to run fsck.foo after x mounts.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
How many people use nilfs? I doubt very many. If you want to add another package to your list that nobody will sign off on, I don't object (even xfsutils and jfsutils rarely get signoffs, and those are popular file systems compared to nilfs).
good point. is jfs really popular? at this point i know very few people who use nilfs, but that should change as it should be a great FS for SSD's. Dieter
Am 07.12.2010 15:03, schrieb Dieter Plaetinck:
On the other hand, I just noticed dosfstools is in extra, whereas aif allows you to install on vfat. This confuses me.
Me too. You definitely can't install on vfat. You can try, but you will fail.
Am Dienstag 07 Dezember 2010 schrieb Thomas Bächler:
Am 07.12.2010 15:03, schrieb Dieter Plaetinck:
On the other hand, I just noticed dosfstools is in extra, whereas aif allows you to install on vfat. This confuses me.
Me too. You definitely can't install on vfat. You can try, but you will fail. root on vfat will never work because of all restrictions, like no symlink support etc. greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Tue, 07 Dec 2010 14:45:45 +0100, Thomas Bächler <thomas@archlinux.org> wrote:
Am 07.12.2010 14:40, schrieb Ionuț Bîru:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
That is not true. Packages don't have to be in core to be included in the installation environment.
I second this. If the reason for moving a package to core is that the installer cannot handle it otherwise the installer needs to be fixed.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
How many people use nilfs? I doubt very many. If you want to add another package to your list that nobody will sign off on, I don't object (even xfsutils and jfsutils rarely get signoffs, and those are popular file systems compared to nilfs).
That's why I would vote against moving it to core. I'd even say we should have a look at those packages in core with low usage and see if we should move them to extra. There are already packages for which we don't get any sign-offs which shows that those are no longer needed to be in core. The idea of core was to provide a minimal set of packages that are needed by nearly all users to set up a base system. Our sign-off procedure ensures that we don't put broken packages by accident there. I don't think that nilfs matches the criteria needed for inclusion in core. (side note: it has 1.38% usage according to pkgstats) Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Tue, 07 Dec 2010 16:26:00 +0100 Pierre Schmitz <pierre@archlinux.de> wrote:
On Tue, 07 Dec 2010 14:45:45 +0100, Thomas Bächler <thomas@archlinux.org> wrote:
Am 07.12.2010 14:40, schrieb Ionuț Bîru:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
That is not true. Packages don't have to be in core to be included in the installation environment.
I second this. If the reason for moving a package to core is that the installer cannot handle it otherwise the installer needs to be fixed.
Like I said in my previous mail, the reason is we only include core on the install images (because core contains all "system-critical utilities"), so if we want to make the user able to install mkfs.nilfs for example, it needs to be in core.
The idea of core was to provide a minimal set of packages that are needed by nearly all users to set up a base system. Our sign-off procedure ensures that we don't put broken packages by accident there.
That makes sense. Although I thought that's what base is for. However, assuming "if you install on a foo-filesystem with aif, you should install foo-utils as well; so that at least your system doesn't break when it needs to run fsck.foo after x mounts" is true (is it?) this would mean we have a problem: on one hand we want to keep core contain only the critical utilities needed by most people, on the other hand we are bleeding edge and want to provide whatever upstream provides - this includes a wide array of filesystem possibilites - except that we can't put the corresponding tools in core when not many folks use them. Dieter
Am Dienstag 07 Dezember 2010 schrieb Dieter Plaetinck:
On Tue, 07 Dec 2010 16:26:00 +0100
Pierre Schmitz <pierre@archlinux.de> wrote:
On Tue, 07 Dec 2010 14:45:45 +0100, Thomas Bächler
<thomas@archlinux.org> wrote:
Am 07.12.2010 14:40, schrieb Ionuț Bîru:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
That is not true. Packages don't have to be in core to be included in the installation environment.
I second this. If the reason for moving a package to core is that the installer cannot handle it otherwise the installer needs to be fixed.
Like I said in my previous mail, the reason is we only include core on the install images (because core contains all "system-critical utilities"), so if we want to make the user able to install mkfs.nilfs for example, it needs to be in core.
The idea of core was to provide a minimal set of packages that are needed by nearly all users to set up a base system. Our sign-off procedure ensures that we don't put broken packages by accident there.
That makes sense. Although I thought that's what base is for.
However, assuming "if you install on a foo-filesystem with aif, you should install foo-utils as well; so that at least your system doesn't break when it needs to run fsck.foo after x mounts" is true (is it?) this would mean we have a problem: on one hand we want to keep core contain only the critical utilities needed by most people, on the other hand we are bleeding edge and want to provide whatever upstream provides - this includes a wide array of filesystem possibilites - except that we can't put the corresponding tools in core when not many folks use them.
Dieter You can fool pacman by adding a extra repo to the iso image, i do this in archboot isos to fix issues with packages that are in extra.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Tue, 07 Dec 2010 15:40:26 +0200 Ionuț Bîru <ibiru@archlinux.org> wrote:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
note that nilfs2 is still marked as experimental in the kernel. it's also marked as experimental in aif. But yes, I request moving it from extra to core, where it belongs (just like all other fs utility packages). This means it will also be on the install cd's. It does not need to be in base, because we want to get filesystem utilities out of base. see: https://bugs.archlinux.org/task/18495 Dieter
Am Dienstag 07 Dezember 2010 schrieb Dieter Plaetinck:
On Tue, 07 Dec 2010 15:40:26 +0200
Ionuț Bîru <ibiru@archlinux.org> wrote:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
note that nilfs2 is still marked as experimental in the kernel. it's also marked as experimental in aif.
But yes, I request moving it from extra to core, where it belongs (just like all other fs utility packages). This means it will also be on the install cd's. It does not need to be in base, because we want to get filesystem utilities out of base. see: https://bugs.archlinux.org/task/18495
Dieter Then please add btrfs too, it's the future filesystem to replace ext4. greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 12/07/2010 03:40 PM, Ionuț Bîru wrote:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
now that aif and the testing iso supports nilfs and Thomas agreed on this [1], i'm going to move this in couples of hours. If you anyone disagrees, please speak now. [1] http://mailman.archlinux.org/pipermail/arch-releng/2011-January/001387.html -- Ionuț
Am Samstag 08 Januar 2011 schrieb Ionuț Bîru:
On 12/07/2010 03:40 PM, Ionuț Bîru wrote:
Hi, i come across https://bugs.archlinux.org/task/20261 and i see Dieter added support in aif for it but it needs to be added in core to include it on the cd.
Don't know why nobody assigned that bug to me since i'm the maintainer of nilfs-utils even since it was in community.
What do you think? Is it worth adding it? It must be in base group?
now that aif and the testing iso supports nilfs and Thomas agreed on this [1], i'm going to move this in couples of hours. If you anyone disagrees, please speak now.
[1] http://mailman.archlinux.org/pipermail/arch-releng/2011-January/001387.html go ahead and move it, we should also move in btrfs.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
participants (5)
-
Dieter Plaetinck
-
Ionuț Bîru
-
Pierre Schmitz
-
Thomas Bächler
-
Tobias Powalowski