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

[Eric Bélanger]

On Sun, Dec 19, 2010 at 12:26 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> 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
>

I agree.  A while ago, I suggested a way to improve signoff for low
usage packages. But it died because of lack of interest. I'll repeat
it here.

Basically, the idea was be to have the devs fill out a list (this
hasn't been updated in a while):

https://wiki.archlinux.org/index.php/DeveloperWiki:CoreSignoffs#List_of_potential_signees_for_low-usage_core_packages

Unfortunately, very few devs bothered filling it out when I created
it, so the process died.

This will tell us what are the low usage packages and how many (and
which) devs can give signoff. This will prevent us having package in
signoff limbo because not enough devs use them. This might encourage
signoffs by getting rid of the "Someone else will signoff" syndrom.

For these low usage packages:

1 - the maintainer could also sent the signoff thread to the
arch-general ML and invite users for signoff. I've already been doing
this for lvm2.

2- we could have a policy so that after a certain amount of days (7
days???) in testing and no bug/problem reported, the package can be
moved to core. The maintainer could bump the thread about halfway
through.  This will eliminate having packages in testing in weeks
waiting for signoffs and will give a clear guideline for maintainers
of these packages.

This could be easily done if there's interest.  It's just a question
of updating the list, have the devs fill it out and decide the minimal
time these packages should remain in testing.

Eric