[arch-dev-public] definition of the core repo, putting nilfs-utils, btrfs-progs and dosfstools in core

[Dan McGee]

On Sat, Dec 18, 2010 at 11:20 PM, Allan McRae <allan at archlinux.org> wrote:
> On 19/12/10 04:59, Dieter Plaetinck wrote:
>>
>> Last time the topic "moving nilfs/btrfs utilities in core"
>> generated some discussion, but no outcome. (and not even all my questions
>> were answered)
>>
>> (http://mailman.archlinux.org/pipermail/arch-dev-public/2010-December/018656.html)
>>
>> So I'll try again, and I'll try to be more clear.
>>
>> question 1:
>> If you install arch linux on a foo-filesystem, should you install
>> foo-utils as well? so that at least your system doesn't break when it
>> needs to run fsck.foo during boot.  IMHO the answer is yes.
>
> Yes.
>
>> question 2:
>> what exacly is the definition of the core repo?
>> Pierre tells me "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."  If is true, what separates base from core?
>> Because this definition looks an awful lot like the definition of base to
>> me.
>>
>> AFAIK core is about bundling all packages which are critical (for the
>> purpose of getting the system to run) for some users,
>> depending on their particular setup.  This is the reasoning why we include
>> the core repo on our core install images,
>> because we say "with this repo, users can install what they need in order
>> to make their system boot and run fine".
>> This is also in line with what I see on
>> https://wiki.archlinux.org/index.php/Official_Repositories ("will
>> provide you with a fully functional base system")
>>
>> This is the problem:
>> - we want to allow users to use new filesystems during installation.
>>  Currently this includes nilfs2 and btrfs.
>>   (marked as experimental in aif).
>> - On the other hand we apparently don't allow infrequently used packages
>> in core. Even if I would wait and only support
>>   these filesystems when they are declared stable, their package usage
>> would still be low.  It would be pretty backwards if I would need
>>   to wait for users to configure their systems using the filesystems
>> manually, so the package usage goes up, before I can include them
>>   on the installation media.
>>   Currently, dosfstools, nilfs-utils and btrfs-progs-unstable are not in
>> core and can't be installed by using a networkless install with the
>> core-images.
>>
>> So, How do we solve this?  I see two outcomes:
>> - we add the packages mentioned above to core, and loosen up the signoff
>> requirements for packages with low usage.
>>   (because "commonly used" and "needed for a base system" are very
>> different things)
>> - we do not add these packages to core, and add something about "must have
>> high usage" on the wikipage i mentioned above.
>>   this also means I will need to include a small repo with "needed for
>> base systems, but with low usage" on the core install images, to
>>   allow users to install these packages.  And I'll need to adapt aif
>> because it now needs to use additional repositories to install
>>   required-to-boot packages.
>>
>> I vote for outcome 1.
>
> Basically I don't care what the outcome is here.   But note that we can
> probably safely assume that reiserfs is more commonly used than both the two
> filesystems that you mention and I have yet to receive a signoff for
> reiserfsprogs (posted 2010-12-04...).   So moving the packages for
> nilfs/btrfs to [core] will only serve to delay updates...  Then again, I see
> no reason why these packages should not be in [core].
>
>
> My solution would be more like your #2 suggestion.  Instead of a "core" CD,
> make an "install" CD which has a set of packages you decide on it. This
> would be largely based on [core], but you can include packages from [extra]
> then too.  You can also drop some [core] packages from the CD. For example,
> there is no point putting gcc-{fortran,objc,ada} on the install CD at all.
>  They are only in [core] because split packages can not go across repos.  So
> get rid of them and gain 40MB more space for your dual arch iso.

I'm of the opposite opinion on this one; I think #1 makes more sense.
We're looking at it backwards- "this package can't go in core because
it is hard to get signoffs" vs. "perhaps we can adjust our signoff
policy for lower-usage core packages". Filesystem utilities, at least
to me, seem like the definition of what core should contain.
Reiser/JFS/XFS/BTRFS/NILFS, while not the top filesystems in use in
Linux, deserve to be supported "out of the box" by us.

-Dan