Re: Disabling automatic upgrades on Sid by default?

[Fabrice BAUZAC]

"M. Zhou"  writes:

> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.

I have read somewhere (where?) an advice for testing/unstable users that
says to upgrade only when you know you will have some time to deal with
an issue, should that occur.

-- 
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Fwd: Disabling automatic upgrades on Sid by default?

[Jerome BENOIT]

 Forwarded Message 
Subject: Re: Disabling automatic upgrades on Sid by default?
Date: Sun, 27 Dec 2020 07:39:42 +0100
From: Jerome BENOIT 
Reply-To: calcu...@rezozer.net
Organisation: ReZoZeR
To: M. Zhou 

Hi,

On 27/12/2020 07:01, M. Zhou wrote:
> Hi folks,
> 
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
> 
> Recently package ppp is pending for upgrade but it does not co-exist
> with my currently installed network-manager. Today when I was shutting
> down my machine, Gnome automatically checked the "install updates ..."
> box for me before I realized its existence. As a result, the system
> reboots and installed ppp by force, removing network-manager and break
> my system for daily use as I need network-manager for wifi-access.
> 
> I've been a daily Sid user for at least 4 years. Automatic upgrades are
> to blame for nearly all my system troubles. And I feel very
> disappointed every time linux behaves like M$ windows.
> 

Are you really sure that Sid is meant for a daily computer ? 


> So, do we have a consensus on whether automatic upgrades should be
> enabled by default?
> 

The consensus is that Sid is broken, hence its name:
the guy next door who breaks my toys on a daily basis.  

Jerome

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

Re: Disabling automatic upgrades on Sid by default?

[Leandro Cunha]

Em dom., 27 de dez. de 2020 às 03:02, M. Zhou  escreveu:

> Hi folks,
>
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
>
> Recently package ppp is pending for upgrade but it does not co-exist
> with my currently installed network-manager. Today when I was shutting
> down my machine, Gnome automatically checked the "install updates ..."
> box for me before I realized its existence. As a result, the system
> reboots and installed ppp by force, removing network-manager and break
> my system for daily use as I need network-manager for wifi-access.
>
> I've been a daily Sid user for at least 4 years. Automatic upgrades are
> to blame for nearly all my system troubles. And I feel very
> disappointed every time linux behaves like M$ windows.
>
> So, do we have a consensus on whether automatic upgrades should be
> enabled by default?
>
>
Hi,

Although you can disable this, I usually update and do most things via the
command
terminal.
Using testing I run apt daily. I like to know what is being updated in the
system.

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Disabling automatic upgrades on Sid by default?

[M. Zhou]

Hi folks,

I don't quite understand the meaning of automatic upgrades on a rolling
system such as Debian/Sid. According to my own experience, such
automatic upgrades could be dangerous.

Recently package ppp is pending for upgrade but it does not co-exist
with my currently installed network-manager. Today when I was shutting
down my machine, Gnome automatically checked the "install updates ..."
box for me before I realized its existence. As a result, the system
reboots and installed ppp by force, removing network-manager and break
my system for daily use as I need network-manager for wifi-access.

I've been a daily Sid user for at least 4 years. Automatic upgrades are
to blame for nearly all my system troubles. And I feel very
disappointed every time linux behaves like M$ windows.

So, do we have a consensus on whether automatic upgrades should be
enabled by default?

Re: Package dependency versions and consistency

[Simon McVittie]

On Sat, 26 Dec 2020 at 14:55:17 -0800, Josh Triplett wrote:
> I'm talking about packaging xyz 1.3.1 and 2.0.1, as separate xyz-1 and
> xyz-2 packages, and allowing the use of both in build dependencies.

This is not all that rare even for C/C++ code, as exemplified by
GTK and other libraries that follow the principles described in
 (written by a then-maintainer of
GTK during the GTK 1.2 to GTK 2 transition). A few examples: GTK, SDL,
libpcre, Allegro, Boost, LLVM, libftdi, libfuse, mozjs; and historically
we also had this for GStreamer, Qt, OpenSSL and WebKitGTK among others.

We try to minimize the number of parallel-installable versions of a
particular library because maintainers and the security team can only
parallelize so far, but the extent to which we can do this depends on
balancing several factors, including the effort required to maintain those
versions, the extent to which they are exposed at security boundaries,
the extent of the incompatibilities, the effort needed and available
upstream or downstream to port all dependent libraries and programs
to the currently-recommended version, and the extent to which we could
accept losing packages still dependent on the old version from Debian.
For example, the Qt/KDE team were able to drop Qt 4 from Debian between
Debian 10 and 11, but GTK 2 certainly can't get the same treatment until
there is a stable release of GIMP that uses GTK 3 or later.

I can see that in language ecosystems that encourage more/smaller packages
than C/C++, or that break API more frequently, we have a scaling problem:
GTK has historically had a new major version about once a decade, which
doesn't represent too many trips through NEW even if it speeds up by
an order of magnitude, but the library ecosystems we're discussing on
this thread are presumably expected to break API/ABI rather more often
than that. (To an extent, typical C/C++ tooling accidentally protects
us from this, by making it so painful to break API/ABI that maintainers
go to great lengths to avoid it.)

Some non-C languages (notably Perl and Python) have a single system-wide
search path and cannot easily accommodate more than one major version
unless they have different names (libdancer-perl, libdancer2-perl;
python3-boto, python3-boto3). However, if a language has a way to ask
for a library by its (name, major version) pair, it would seem sensible
for any Debian-specific machinery around it to usually map
(name, major version) pairs (as opposed to bare names) to installation
filenames/directories and Debian package names.

The GObject-Introspection bindings for GLib-based libraries like GTK
are another example of this, if you look at them from an appropriate angle:
for example, the gir1.2-gtk-3.0 package contains Gtk-3.0.typelib, which
is installable in parallel with Gtk-2.0.typelib and Gtk-4.0.typelib.

smcv

Re: Package dependency versions and consistency

[Josh Triplett]

Adrian Bunk wrote:
> On Fri, Dec 18, 2020 at 04:25:19PM -0800, Josh Triplett wrote:
> >...
> > I'm not suggesting there should be 50 versions of a given
> > library in the archive, but allowing 2-4 versions would greatly simplify
> > packaging, and would allow such unification efforts to take place
> > incrementally, via transitions *in the archive* and *in collaboration
> > with upstream*, rather than *all at once before a new package can be
> > uploaded*.
> > 
> > (I also *completely* understand pushing back on having 2-4 versions of
> > something like OpenSSL; that'd be a huge maintenance and security
> > burden. That doesn't mean we couldn't have 2-4 semver-major versions of
> > a library to emit ANSI color codes, and handle reducing that number via
> > incremental porting in the archive rather than via prohibition in
> > advance.)
> 
> It is important to always remember that the main product we are 
> delivering to our users are our stable releases.

(This is somewhat off-topic, but: I think that Debian stable is *one* of
the main products of Debian, but not by any means the only one. Debian
testing and unstable/experimental are also incredibly valuable. We need
solutions that work for all of those. Those solutions *do* need to work
for stable as well, though, and I'll address the rest of your mail in
that regard.)

> We do have 4 different versions of autoconf in the archive.
> This works because autoconf does not have CVEs.

There's a great deal of software out there with similar properties, most
notably that it doesn't sit at a security boundary. That doesn't just
include build-time code. Also, some types of security vulnerabilities
are rare-to-nonexistent in other ecosystems. A library, written in a
safe language, whose job is to generate ANSI terminal color codes, is
not likely to have security vulnerabilities. It's not critical to force
all packages to move to the latest version of that library immediately,
before they can upload at all.

Bundling *can* make it much more difficult to handle security support,
for a variety of reasons (updating distinct embedded copies, dealing
with more version skew, etc). But in the absence of bundling, if the
*only* issue is that there may be 2-4 semver-major versions in the
archive, I'd expect the process to be roughly "upload new versions of
those packages, trigger rebuilds of dependencies". On balance, I
wouldn't expect substantial scaling issues with the former. The *latter*
would be where we may need some tooling improvements, for ecosystems
that do the equivalent of static linking or library bundling at build
time and ship a compiled artifact in their binary package.

> If a library is so complex that your "unification efforts in 
> collaboration with upstream" would apply, chances are there
> will be CVEs if anyone does a security audit of the code.

I'm not talking about complexity of an individual library; that's not
the primary issue here. I'm talking about quantity. If your package has
300 dependencies, most of which are relatively small, focused,
self-contained libraries, the "collaboration with upstream" part is
about collaboration with the upstream of your package, not the upstreams
of the dependencies.

If you want to package abc version 1.2.3, and among many other things,
abc depends on xyz version 2.1.4, and xyz has a new version 3.0.1 now,
it makes sense to work with the upstream of abc, sending them a patch to
migrate to the new version, and waiting for abc 1.2.4 to come out with
that update. It *doesn't* make sense to maintain a downstream Debian
patch to make abc work with the newer xyz. abc can just build-depend on
xyz-2, and a later version of abc can build-depend on xyz-3. That isn't
a reflection of complexity in xyz, or in abc.

Also, sometimes those dependencies are indirect through other
dependencies, and to transition forward, you may want to move multiple
dependencies forward in concert, for compatibility reasons or just to
minimize duplication within one application.

> > I think much of our resistance to allowing 2-4 distinct semver-major
> > versions of a given library comes down to ELF shared libraries making it
> > painful to have two versions of a library with distinct SONAMEs loaded
> > at once, and while that can be worked around with symbol versioning,
> > we've collectively experienced enough pain in such cases that we're
> > hesitant to encourage it. Our policies have done a fair bit to mitigate
> > that pain. But much of that pain is specific to ELF shared libraries and
> > similar.
> 
> No, the only real pain is providing security support.

Debian has gone through many library transitions that have incurred
substantial pain, including those where a lack of symbol versioning
resulted in serious issues if two versions of the same library ended up
in the same address space. That's in addition to the normal pain of
library transitions, and in addition to all the *infrastructure* that
Debian has built up around library versi

Bug#978149: ITP: pyenv -- Simple Python version management

[karthek]

Package: wnpp
Severity: wishlist
Owner: karthek 
X-Debbugs-Cc: debian-devel@lists.debian.org, m...@karthek.com

* Package name: pyenv
  Version : 1.2.21
  Upstream Author : 2013 Yamashita, Yuu
* URL : https://github.com/pyenv/pyenv
* License : Expat
  Programming Lang: shell script
  Description : Simple Python version management

 pyenv lets you easily switch between multiple versions of Python. It's 
 simple, unobtrusive, and follows the UNIX tradition of single-purpose 
 tools that do one thing well.
 pyenv does:
* Let you change the global Python version on a per-user basis.
* Provide support for per-project Python versions.
* Allow you to override the Python version with an environment
* variable.
* Search commands from multiple versions of Python at a
  time. This may be helpful to test across Python versions with tox.

It is useful when youre working on a project where they expect you to
work in a LTS version of some distro (like Ubuntu LTS) and they dont
bother mainataining aompatibility with newer python versions.

I plan to mantain it and need a sponsor

Bug#978133: ITP: golang-github-go-playground-universal-translator -- translator for Go using CLDR data and pluralization rules

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-go-playground-universal-translator
  Version : 0.17.0-1
  Upstream Author : Go Playgound
* URL : https://github.com/go-playground/universal-translator
* License : Expat
  Programming Lang: Go
  Description : translator for Go using CLDR data and pluralization rules

 Universal Translator is an i18n Translator for Go using CLDR data and
 pluralization rules. This package is a thin wrapper around its
 locales counterpart (golang-github-go-playground-locales-dev) in
 order to store and translate text for use in your applications.
 .
 Features:
  - Rules generated from the CLDR data
  - Contains Cardinal, Ordinal and Range Plural Rules
  - Contains Month, Weekday and Timezone translations
  - Contains Date & Time formatting functions
  - Contains Number, Currency, Accounting and Percent formatting
functions
  - Supports the Gregorian calendar only
  - Supports loading translations from files
  - Supports exporting translations to files


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#978128: ITP: golang-github-go-playground-locales -- set of locales generated from the CLDR Project

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-go-playground-locales
  Version : 0.13.0-1
  Upstream Author : Go Playgound
* URL : https://github.com/go-playground/locales
* License : Expat
  Programming Lang: Go
  Description : set of locales generated from the CLDR Project

 This set of locales was generated from the CLDR Project, and can be
 used independently or within an i18n package; the primary target is
 supplementing go-playground's universal-translator.
 .
 Features:
  - Rules generated from CLDR data v31.0.1
  - Contains Cardinal, Ordinal and Range Plural Rules
  - Contains Month, Weekday and Timezone translations
  - Contains Date & Time formatting functions
  - Contains Number, Currency, Accounting and Percent formatting
functions
  - Supports the Gregorian calendar only


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#978121: ITP: golang-github-leodido-go-urn -- Go parser for Uniform Resource Names

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-leodido-go-urn
  Version : 1.2.1-1
  Upstream Author : Leo Di Donato
* URL : https://github.com/leodido/go-urn
* License : Expat
  Programming Lang: Go
  Description : Go parser for Uniform Resource Names

 This parser deals with Uniform Resource Names as defined in RFC 2141
 (URN Syntax). The actual parsing is accompanied by:
  - fine-grained and informative erroring;
  - namespace specific string normalization.


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature