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

[Allan McRae]

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.

Allan