gnewsense-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnewsense-dev] Stepping down


From: Sam Geeraerts
Subject: Re: [Gnewsense-dev] Stepping down
Date: Fri, 2 Aug 2019 22:43:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Icedove/52.9.1

On 31/07/19 01:05, Paul Boddie wrote:
>> 1) Copy Debian's package repository.

This is done by debmirror. Our main mirror holds a (private) copy of
Debian's repo to derive gNS's repo from.

>> 2) Identify the packages that don't align with the Free Software 
>> Distribution Guidelines or that contain Debian specific branding. 
>> 3) For each of those packages: 3a) Unpack the source 3b) Modify the
>> code 3c) Update version info, changelog and other package metadata 
>> 3d) Repackage source and build binaries

This is pretty well explained in [1]. The source package gets uploaded
to build servers, where pbuilder produces binary packages.

>> 4) Replace those packages in the package repository

Source and binaries are copied to the main mirror. The work horse there
is reprepro. It brings gNS's repo up to date with the local Debian repo,
minus non-free stuff (purge list), plus the newly built packages (in the
incoming directory). I wrote Debderiver [2] as a thin layer on top of
that to deal with the intricacies of reprepro and make it easier to have
a repo layout like "ucclia-security" instead of "ucclia/updates".

Getting a deeper understanding of how this step works mostly involves
reading reprepro's manpage and wrapping your head around terminology
(distribution, suite, component, pocket, ...).

>> 5) Build installer images

This is done with live-build.

> There is a planning page for gNewSense 5 that seems to indicate some
> ideas that have yet to be realised:
> 
> http://www.gnewsense.org/DevelopmentProjects/Gnewsense5

Builder has been reworked a bit, but so far not yet to a usable state.

> It seems to me that Debian itself reinvents its own wheels all the
> time to the point of being incoherent: the derivatives page gives
> plenty of evidence of such, and anyone with exposure to Debian
> packaging should be familiar with lots of ways of doing the same
> thing, tools that once did a handful of things now trying to do
> everything, and so on.

Packaging itself is more standardized than it used to be, but some
developers have their own ways and some software is harder to package.
Creating a derivative is another matter and there's still much
opportunity for standardization.

> Also, having looked at building other non-Debian distros and
> generally not succeeding (for various reasons), having a way of
> building a fairly minimal distribution might be useful and
> confidence-building. (This is prohibitive with stuff like Guix due to
> the nature of the thing.)

I found that (in the case of Debian) there's a lot of overhead involved
with regards to rebranding, and not just the visible stuff. You have to
add your keyring, point to your own mirrors, add/overwrite the distro
name at various levels, add/replace artwork etc. Luckily, packages have
become more derivative-friendly over the years, so adding a
configuration file is getting more common than having to edit source code.

> My interest has been to build a "libre" distro for MIPS32

Note that Debian is dropping support for mips32 [3].

[1] http://www.gnewsense.org/Processes/Packaging
[2] http://bzr.savannah.gnu.org/lh/gnewsense/debderiver/files
[3] https://lists.debian.org/debian-mips/2019/07/msg00010.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]