[yocto] Dropping Debian 7 as supported?

[Jens Rehsack]

> Am 14.02.2016 um 11:24 schrieb Richard Purdie <richard.purdie at linuxfoundation.org>:
> 
> On Sat, 2016-02-13 at 10:12 -0800, Khem Raj wrote:
>> On Sat, Feb 13, 2016 at 9:28 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>>> On Sat, 2016-02-13 at 15:30 +0100, Jens Rehsack wrote:
>>>>> Am 11.02.2016 um 15:32 schrieb Burton, Ross <
>>>>> ross.burton at intel.com>
>>>>> :
>>>>> 
>>>>> 
>>>>> On 11 February 2016 at 14:21, Nick Leverton <nick at leverton.org>
>>>>> wrote:
>>>>> Possibly a little early - Debian 7 will be going onto LTS
>>>>> security
>>>>> support for
>>>>> two years, starting some time this month.  Quoting from
>>>>> https://wiki.debian.org/LTS
>>>>> 
>>>>> Ah yes, I'd forgotten about the LTS project and was looking at
>>>>> the
>>>>> security team.
>>>>> 
>>>>> This does make it less clear, but it's still an old release and
>>>>> we
>>>>> can't support/test on everything.
>>>> 
>>>> Sure, but are there some serious/expensive maintaining efforts
>>>> continuing support Debian 7?
>>>> Or is it an approach to kick Debian from list of supported
>>>> distributions for (above?) reasons?
>>>> 
>>>> Since I run some build instances on a Debian 7 machine which is
>>>> not
>>>> going to be upgraded that
>>>> soon (don't want Debian 8, but don't want to reinstall from
>>>> scratch
>>>> and migrate my Xen VM's ...),
>>>> dropping support for "it's just time to move on" is more a
>>>> Desktop
>>>> philosophy, not for embedded/datacenter
>>>> approaches ...
>>> 
>>> For example, we'd like to use the sparse option when building
>>> rootfs:
>>> 
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9099
>>> 
>>> This support isn't available in the version of dd in debian 7. Our
>>> options are:
>>> 
>>> * Build a dd -native

That's something complete different than "End of regular support, switching
to LTS" - so based on missing features, any distribution which doesn't
fulfill the required features should be discarded from list of supported
distributions unless the required features are Yocto patches in upstream.
In such a case the drop smells like misusing power (then a smoother way
should be found),

>> For core feature like sparse files its better to control our own
>> destiny and use dd-native regardless.
> 
> There are certain core utilities which its very hard to add into the
> dependency chains correctly. With xz, I recently gave up trying to get
> the patches right. I'm sure it could be done, it didn't seem worth the
> effort though. dd and other coreutils fall into the same category, very
> hard to get right without races. There is probably a redesign of the
> some of the way staging happens needed to make it work and that is a
> low priority right now.

Having an implicit xy.bbclass adding dependency to yocto-coreutils-native
isn't a way? As said several times, my pkgsrc background leads me to
Yocto for embedded Linux development - and this background educated add
nb* utilities for each host utility which is incompatible to the
infrastructure.

>> But that does not mean we should
>> not drop debian7 or arcane centos distros that we keep supporting for
>> ever. I still see patches for centos 5.8 in metadata.
> 
> We did retire centos 6 recently (qemu wouldn't run there correctly for
> any of the automated tests).

Which is again a good reason for retiring support for a dedicated
distribution. I'm a bit torn regarding the lifecycle of RHEL/Cent OS,
which is 10 years after release - dropping support for enterprise
grade distribution to quick leaves a taste/smell ... (don't know how to
express).

Don't get me wrong - it is absolutely reasonable to retire distributions
lacking important features which can't be added with reasonable effort
into build chain. Deciding which important feature requires such a
retirement should be proved with an eye of lifecycle of server distributions.

Cheers
--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160215/98cab4f8/attachment.pgp>