[Freedombox-discuss] How do we handle package upgrades on the Freedombox?

Jonas Smedegaard dr at jones.dk
Mon Apr 14 22:05:43 UTC 2014


Quoting Petter Reinholdtsen (2014-04-14 22:41:30)
> I've been running an old freedombox image for a while, and upgraded it 
> regularly, and so far I have seen two conffile questions, one for 
> /etc/dnsmasq.conf and another for /etc/tor/torrc.  I assume upgrades 
> should be handled using the plinth interface or using the 
> unattended-upgrades package, and I suspect neither option will handle 
> conffile questions well.
> 
> Did any of you figure out how we should handle upgrading the deb 
> packages installed on a freedombox, for security fixes and newer 
> versions?

I have written several times about that very issue on this list.  Here's 
an early example (few months after birth of the list):

Quoting Jonas Smedegaard (2010-09-01 13:07:45)
> I strongly recommend FreedomBox to be a Debian thing, rather than an 
> on-top-of-Debian thing. I.e. *not* act on configfiles from a sysadmin 
> point of view but as part of Debian, obeying Debian Policy which 
> mandates no automated interaction directly with the content of other 
> packages.  We should not make same mistake as Debian Edu in relying on 
> Debian only for a) initial install and b) maintainance of _binary_ 
> packaging parts, but also for c) maintainance of configfiles.
>
> It is a *much* slower process to convince a Debian package maintainer 
> to implement reliable packaging configurability for our needs than to 
> hack ourselves on top of an installed package, but all hacks we invent 
> we must *maintain* too, which is too likely to bit-rot down the road.

Here's another one where I mention you:

Quoting Jonas Smedegaard (2011-09-15 19:44:19)
> CFengine, Puppet, Chef, FAI, etc. are excellent helper tools for 
> system administration.
>
> An essential goal of FreedomBox, however, is to be dead easy to use. 
> Which in my experience means avoid the system administrator role!
>
>
> You may disagree with me.  Others do - including the main developer of 
> Skolelinux, Petter Reinholdtsen.  Watch between 31:20 and 33:31 of 
> this: 
> http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/779_Debian-Edu_Current_Status_and_Development_Ideas_for_the$
>
> What we talk about there is Debian bug#311188 which Petter disagrees 
> with me is a violation of Debian policy, but agrees is causing 
> Skolelinux to not be automatically upgradeable from one stable release 
> to the next.
>
>
> I do not want to tell our users that the way to upgrade to a newer 
> version of FreedomBox is to flash [it]!

When Plinth directly edits configuration files, it is an administrators' 
tool.

Solution is to have Plinth only ever communicate with debconf!

...and convince various package maintainers (e.g. by offering patches) 
to implement via debconf the configuration flexibility that we need.


Here's a third one, addressing the temptation to cheat e.g. by storing 
LDAP configuration inside the LDAP database:

Quoting Jonas Smedegaard (2010-09-02 00:07:31)
> However we apply a UI on top, we need to decide on whether we want to 
> obey the programmatic interfaces offered by the Debian packagings [or] 
> bypass them and instead work directly with the underlying configfiles, 
> config databases and whatever other config mechanisms available inside 
> the pieces packaged.
>
> Whether we want FreedomBox to benefit from Debian *maintainance* of
> package configurations, or think we are better at that than Debian!


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20140415/3efc7d1c/attachment.sig>


More information about the Freedombox-discuss mailing list