Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #8643 > unrolled thread

third-party packages adding apt sources

Back to article view | Back to linux.debian.project

Contents

  third-party packages adding apt sources Daniel Pocock <daniel@pocock.pro> - 2016-05-19 17:20 +0200
    Re: third-party packages adding apt sources Paul Tagliamonte <paultag@debian.org> - 2016-05-19 17:50 +0200
      Re: third-party packages adding apt sources Bas Wijnen <wijnen@debian.org> - 2016-05-19 19:00 +0200
        Re: third-party packages adding apt sources "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2016-05-19 19:10 +0200
        Re: third-party packages adding apt sources Mike Hommey <mh@glandium.org> - 2016-05-20 00:40 +0200
        Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-20 07:30 +0200
          Re: third-party packages adding apt sources Antonio Terceiro <terceiro@debian.org> - 2016-05-20 14:00 +0200
            Re: third-party packages adding apt sources The Wanderer <wanderer@fastmail.fm> - 2016-05-20 14:30 +0200
            Re: third-party packages adding apt sources Ole Streicher <olebole@debian.org> - 2016-05-20 15:00 +0200
              testing is a tool for the release team (Re: third-party packages  adding apt sources Holger Levsen <holger@layer-acht.org> - 2016-05-20 15:10 +0200
            Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-20 20:40 +0200
          Re: third-party packages adding apt sources Paul Wise <pabs@debian.org> - 2016-05-21 08:10 +0200
        Re: third-party packages adding apt sources Tollef Fog Heen <tfheen@err.no> - 2016-05-20 14:50 +0200
      Re: third-party packages adding apt sources Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-05-19 20:20 +0200
    Re: third-party packages adding apt sources Russ Allbery <rra@debian.org> - 2016-05-19 17:50 +0200
      Re: third-party packages adding apt sources Holger Levsen <holger@layer-acht.org> - 2016-05-19 18:00 +0200
    Re: third-party packages adding apt sources Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-05-19 19:10 +0200
      Re: third-party packages adding apt sources Daniel Pocock <daniel@pocock.pro> - 2016-05-19 19:20 +0200
        Re: third-party packages adding apt sources Bas Wijnen <wijnen@debian.org> - 2016-05-19 19:50 +0200
          Re: third-party packages adding apt sources Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-05-19 20:20 +0200
        Re: third-party packages adding apt sources Russ Allbery <rra@debian.org> - 2016-05-19 20:20 +0200
        Re: third-party packages adding apt sources Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-05-19 20:20 +0200
      Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-20 07:40 +0200
        Re: third-party packages adding apt sources Charles Plessy <plessy@debian.org> - 2016-05-20 11:40 +0200
        Re: third-party packages adding apt sources Paul Wise <pabs@debian.org> - 2016-05-21 08:10 +0200
          Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-21 08:50 +0200
            Re: third-party packages adding apt sources Paul Wise <pabs@debian.org> - 2016-05-21 09:00 +0200
              Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-21 09:10 +0200
          Re: third-party packages adding apt sources Lars Wirzenius <liw@liw.fi> - 2016-05-21 09:40 +0200
            Re: third-party packages adding apt sources Martin Steigerwald <martin@lichtvoll.de> - 2016-05-21 10:30 +0200
            Re: third-party packages adding apt sources Martin Steigerwald <martin@lichtvoll.de> - 2016-05-21 10:30 +0200
              Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-21 11:00 +0200
                Re: third-party packages adding apt sources Martin Steigerwald <martin@lichtvoll.de> - 2016-05-21 11:30 +0200
          Re: third-party packages adding apt sources Martin Steigerwald <martin@lichtvoll.de> - 2016-05-21 10:10 +0200
            Re: third-party packages adding apt sources Lars Wirzenius <liw@liw.fi> - 2016-05-21 10:40 +0200
              Re: third-party packages adding apt sources Martin Steigerwald <martin@lichtvoll.de> - 2016-05-21 11:20 +0200
        Re: third-party packages adding apt sources Ole Streicher <olebole@debian.org> - 2016-05-21 10:00 +0200
          Re: third-party packages adding apt sources Vincent Bernat <bernat@debian.org> - 2016-05-21 11:00 +0200
    Re: third-party packages adding apt sources Hakan Peker <holypeker@manlymail.net> - 2016-05-19 19:50 +0200
      Re: third-party packages adding apt sources Vincent Danjean <vdanjean.ml@free.fr> - 2016-05-20 21:40 +0200
        Re: third-party packages adding apt sources Hakan Peker <holypeker@manlymail.net> - 2016-05-22 16:50 +0200
          Re: third-party packages adding apt sources Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2016-05-22 17:10 +0200
    Re: third-party packages adding apt sources Charles Plessy <plessy@debian.org> - 2016-05-21 05:50 +0200
    Re: third-party packages adding apt sources Paul Wise <pabs@debian.org> - 2016-05-21 07:50 +0200
      Re: third-party packages adding apt sources Adam Borowski <kilobyte@angband.pl> - 2016-05-21 14:40 +0200
        Re: third-party packages adding apt sources Paul Wise <pabs@debian.org> - 2016-05-22 03:50 +0200

Page 1 of 3  [1] 2 3  Next page →

#8643 — third-party packages adding apt sources

More and more frequently I'm encountering systems where third-party
repositories have been added into /etc/apt/sources.list or
/etc/apt/sources.list.d, usually put there by some .deb package that a
user installed from some third party site.

There are a few things going on here:

a) the .deb format is convenient and respected so when a user sees a
.deb file, they have the impression it is easy to install and
potentially trustworthy

b) many upstreams appear frustrated about getting their package
officially supported in Debian.  Sometimes there is good reason their
package doesn't belong in Debian but sometimes it is more about inertia
in Debian or the upstream isn't aware about backports and thinks their
package will be stuck at a particular version forever

From a technical perspective, can we do more to prevent users being
surprised by packages putting new entries in /etc/apt/sources.list.d?

From an organizational perspective, can we do more to make contact with
such upstreams and try to find ways to involve them in releasing their
packages through official channels?  Is there any way we could gather
data about how many upstreams do this without compromising user privacy?

[toc] | [next] | [standalone]

#8644

[Multipart message — attachments visible in raw view] — view raw

[cc'ing devel, since this is a rant that involves technical topics, and
 god knows I only go on so many rants a year these days]

On Thu, May 19, 2016 at 05:18:28PM +0200, Daniel Pocock wrote:
> b) many upstreams appear frustrated about getting their package
> officially supported in Debian.

Yeah, I don't think that's it. "officially supported" is burrying a lot
of really important discussion we're not having.

> Sometimes there is good reason their
> package doesn't belong in Debian but sometimes it is more about inertia
> in Debian or the upstream isn't aware about backports and thinks their
> package will be stuck at a particular version forever

Frankly, I have a hell of a lot of sympathy for this.

Backports are a whole thing. People have to be actively aware of them.
Users have to be told to add a new thing in the sources by hand, and
install something explicitly. It's calories, and explaining a Debian
process to a user isn't fun. Why would upstreams want to do this?


My claim, as I'll outline below, is, if the upstream wants to give the
user an up-to-date software package, and they have to teach them how to
add a new archive, they'll give them an archive *they control*, because
they're now on the hook for delivering through that channel. Upstream
wants to spend as little time as they can with this, so they make it
easy - they make a deb.


Now, for the rant I promised.


Backports are present when a package is in testing, and backports are a
single channel. Backports are not for upstream's releases, whenever they
want to ship a thing.

We have zero procedure in place for the following:

  - Totally unsupported very old version of ${FOO} in stable, maintainer
    isn't patching bugs, bugs are going to upstream, and upstream is
    annoyed Debian has out of date, perhaps insecure thing X.

  - Leaf package ${BAR} has a robust upstream community, where releases
    are very well tested, with a mature stable/unstable release cycle.
    Our stable release freeze was off by a few months, so we've been
    shipping their 'oldstable' in our 'stable' for years. The
    maintainers are annoyed we don't use the latest stable in our
    stable.


We can talk about what is an isn't right all day long, or about how PPAs
are going to solve all this one day, but I've become more and more
worried that we're failing to serve users in this way.

Largely, I think the first situation is a common one that our culture
has forced people to group-think "Well, that's bad and the system is
working as intended". We can't let software change on our stable
installs, so this situation is bad, but the intent of stable.

The second one is harder to say that with, since upstream is making
assertions (just as strong as us) on some things. Be it protocol
stability, API stability, or whatever.

We're mostly approximating #2 by stacking up patches from their next
stable, and applying them to our stable. We're basically shipping the
new version with the old version number, without as much testing as the
real version, and only confusing ourselves (patches are a bitch), users
(I have version 1.2), and upstreams (why doesn't Debian trust the
release process), causing tension everywhere. Look at OpenSSL, it's
nuts. (God bless the OpenSSL team for doing this, and finding a way to
keep DDs happy -- or rather -- merely quiet, as well as upstreams and
users).

So, your question, why do people try to make it easy to get the latest
stable software is answered simply with "because we're not". We are the
problem. No one wants to do this. Maintianing an archive sucks. No one
wants to maintain a Debian archive. It's just the least work to deliver
something supportable and maintainable to users.

Go to any mature project, they have a way to bypas the archive, and get
the latest stable from upstream. This is a huge failure. Upstreams
aren't becoming DDs and updating packages, dispite the fact they can
package and maintain things.

Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
*external archives* because it's easier.

The issue is, we have a model of software delivery that's slowly growing
more and more distant from the realities of shipping software today. Why
is this? What can we do? What do our users want? What do our users
*expect*?

Making it hard to install a new archive will only lead to more
workarounds, more FAQs telling users to dismiss warnings, and more
upstreams hell-bent on working against us, because we keep making their
lives harder.


This is a 100% larger conversation, and it's not about a hacky deb, it's
about how our place in the software ecosystem has been evolving, and we
need to evolve with it, or we'll find ourselves part of the problem we
were trying to solve in the first place.

[toc] | [prev] | [next] | [standalone]

#8647

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, May 19, 2016 at 11:46:53AM -0400, Paul Tagliamonte wrote:
> [cc'ing devel, since this is a rant that involves technical topics, and
>  god knows I only go on so many rants a year these days]

You didn't actually do this.

> > Sometimes there is good reason their
> > package doesn't belong in Debian but sometimes it is more about inertia
> > in Debian or the upstream isn't aware about backports and thinks their
> > package will be stuck at a particular version forever
> 
> Frankly, I have a hell of a lot of sympathy for this.

So do I, but I disagree with your solution.  Here's how I see it:

Debian stable is for users who want a rock solid system.  It is out of date by
the nature of how it is built.  Users who want to get the newest versions of
their software should not be running stable; testing is probably better for
them.

When programs get packaged outside of unstable, we should look at why that
happens, and try to convince the packager to do it inside Debian instead.
(This convincing may take the form of adding features to our system that solve
their problems.)

When users or upstreams complain that the version in stable isn't up to date,
we should explain to the users that they probably want to use testing.  If this
is a common problem for upstreams, our user documentation about this is not
sufficiently clear.

When users want to run stable with one or two packages cherry-picked from
backports, that is something which we may want to make easier for them.

> Backports are a whole thing. People have to be actively aware of them.
> Users have to be told to add a new thing in the sources by hand, and
> install something explicitly. It's calories, and explaining a Debian
> process to a user isn't fun. Why would upstreams want to do this?

Agreed, we should make this easier; allow DDs and the package uploader to
trigger building a backport for any package that is in testing by sending an
e-mail, perhaps?

And aside from that, I agree that it should be easier to install a system that
includes backports in the sources.list.

> My claim, as I'll outline below, is, if the upstream wants to give the
> user an up-to-date software package, and they have to teach them how to
> add a new archive, they'll give them an archive *they control*, because
> they're now on the hook for delivering through that channel. Upstream
> wants to spend as little time as they can with this, so they make it
> easy - they make a deb.

Yes.  I do this myself for some experimental packages that I don't consider
ready for the general public yet.  That is IMO a valid reason for having a
private repository.  "Doing it right is too hard" is not; that is something we
should fix.

> Backports are present when a package is in testing, and backports are a
> single channel. Backports are not for upstream's releases, whenever they
> want to ship a thing.

If we make it easy for them to become DDs or DMs and for uploaders to trigger
backports builds, backports can be what upstream wants.

> We have zero procedure in place for the following:
> 
>   - Totally unsupported very old version of ${FOO} in stable, maintainer
>     isn't patching bugs, bugs are going to upstream, and upstream is
>     annoyed Debian has out of date, perhaps insecure thing X.

Yes, this is a different problem.  We may want to shield upstream from
bugreports for those packages somehow.

IMO it would be good to recommend our users to file all bugs with us, and leave
it to the maintainer to pass them to upstream.  I have upstreams that follow
our bug tracker, which is great.  But if they don't, it should be up to me to
decide whether the report is worth their time.

>   - Leaf package ${BAR} has a robust upstream community, where releases
>     are very well tested, with a mature stable/unstable release cycle.
>     Our stable release freeze was off by a few months, so we've been
>     shipping their 'oldstable' in our 'stable' for years. The
>     maintainers are annoyed we don't use the latest stable in our
>     stable.

If the bugreports go through us, they shouldn't have a problem with this.  It
is up to the users to choose who they trust.  If they trust upstream not to
break things (which for some upstreams is totally justified, but for others it
isn't), they can get the new package from backports (assuming that we made that
easy, so the new version is in there).  If they only trust us, they use the
older version and there is nothing wrong with that.  If upstream doesn't want
that to happen, tough luck.  It's our job to give users what they want, not to
force onto them what upstream wants.

> Largely, I think the first situation is a common one that our culture
> has forced people to group-think "Well, that's bad and the system is
> working as intended". We can't let software change on our stable
> installs, so this situation is bad, but the intent of stable.

I think it is the intent of stable, and it's good.  There are some improvements
to be made, especially in terms of shielding upstream from irrelevant bug
reports and making backports easier to use both for upstream and users, but
other that I don't see a problem.  Perhaps educating users about whether they
should be using stable or testing is also a part of this.

> The second one is harder to say that with, since upstream is making
> assertions (just as strong as us) on some things. Be it protocol
> stability, API stability, or whatever.

It's up to the users to judge these assertions.  If they want to trust them, we
should make it easy to use the packages through backports.  But if the user
wants to trust Debian only, including its freeze process, that means they want
the old version and we should provide exactly that.

> Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> *external archives* because it's easier.

This indicates that our procedures are too hard.  That needs to be fixed.
Maybe people from those teams are reading this and can comment on it?

> Making it hard to install a new archive will only lead to more
> workarounds, more FAQs telling users to dismiss warnings, and more
> upstreams hell-bent on working against us, because we keep making their
> lives harder.

Yes.  But I'm reluctant to throw away our stable release process.  If it's not
for everyone (and it isn't), we should be more clear about that.

Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXPew6AAoJEJzRfVgHwHE61u0P/jxrzL0Rc2XAAzU2Wo5JZdj5
BErMfNczOxBmsE92PBPdW35tT+7PdzlGRZQI11yMuZHOBq/C/EM5TGAnIyJrsisM
etUBIdY8w6qYnj79vbi5RqfbqcCyQkmb/RYtXsB0Wjfj0k8VHE5r4NCCU9ySFYBq
pjbY2WokeTmtOyFENcLFNFgtMPHqCfhLSoA+/YmnYfLpiX7nGzVD5J+YGS+sDLxf
4KfDnOylxXwzywE/tnE+l8w82RoT7hPHnW+0JqEwFenVhaNhKJunsfB++o0k7owx
kNtPRO96Z2e8/V794E/Ke83gUS5vFyOPPsiEVawvsN0IUX9WTGP0ymg+E28Y8Wb5
5Z5hAljXZVt/oRm34Ukb5BdHFDsssvsuBivZ0HTCvEfMKYETpev1SYN0gpx8v232
vpvHcBZr1AKXQ2rpWDxrPrLcNpyarDF13KILKBXLyRDdYWZttwECA931YWw21Ztj
SDH0bGC7Cb3/DGO7lz/vpOFhjrs4nUi+6eEkZtSYyoRoZ0/ovEnYg1Y+6/oRVmRQ
3nLTVz1TZnYT4nMna0DG9J9bxRsTqXM1fd1mslIg4c1Z6VUxW40Ukd+wDVxPJlaV
mK9K5WrLM4dYPlvgHBRSKfdTOEcZ/DSjdSMyYy+1cGNrJWz04ia9VjieKU87SiVu
IrYJcfdy2Rfuicap08dQ
=4m3S
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#8649

On 2016-05-19 17:39, Bas Wijnen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, May 19, 2016 at 11:46:53AM -0400, Paul Tagliamonte wrote:
>> [cc'ing devel, since this is a rant that involves technical topics, 
>> and
>>  god knows I only go on so many rants a year these days]
> 
> You didn't actually do this.

https://lists.debian.org/debian-devel/2016/05/msg00277.html disagrees 
(modulo quibbles on naming).

Regards,

Adam

[toc] | [prev] | [next] | [standalone]

#8657

On Thu, May 19, 2016 at 04:39:24PM +0000, Bas Wijnen wrote:
> > Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> > *external archives* because it's easier.
> 
> This indicates that our procedures are too hard.  That needs to be fixed.
> Maybe people from those teams are reading this and can comment on it?

FWIW, I'm maintaining mozilla.debian.net because we still don't have no
freaking PPAs despite the announcement a few years ago that we would have
them soon. I'm not holding my breath. Also because the process for
backports doesn't allow things that are not in testing to be in
backports, which means it is not possible to have a non ESR firefox
there.

Mike

[toc] | [prev] | [next] | [standalone]

#8658

[Multipart message — attachments visible in raw view] — view raw

 ❦ 19 mai 2016 16:39 GMT, Bas Wijnen <wijnen@debian.org> :

> Debian stable is for users who want a rock solid system.  It is out of date by
> the nature of how it is built.  Users who want to get the newest versions of
> their software should not be running stable; testing is probably better for
> them.

testing is not suitable for most people because:

 1. no security support
 2. packages can disappear at any time

There was some discussion in the past to turn testing into a rolling
release but nothing was done. Such a project would be interesting to
check its adoption. People complaining that stuff is too old could be
directed to this rolling release version and we will likely get people
complaining that stuff moves too fast, but at least, we can't be blamed
to ship too old softwares, that would be a user choice.
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
		-- Shakespeare, "King Lear"

[toc] | [prev] | [next] | [standalone]

#8661

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
>  ❦ 19 mai 2016 16:39 GMT, Bas Wijnen <wijnen@debian.org> :
> 
> > Debian stable is for users who want a rock solid system.  It is out of date by
> > the nature of how it is built.  Users who want to get the newest versions of
> > their software should not be running stable; testing is probably better for
> > them.
> 
> testing is not suitable for most people because:
> 
>  1. no security support

That's not true. Proper security fixes will get into testing after 2
days in unstable if everything goes right as long as the maintainer, or
something that cares, does the work.

>  2. packages can disappear at any time

If they are broken. In my book that a feature and not a bug.

> There was some discussion in the past to turn testing into a rolling
> release but nothing was done. Such a project would be interesting to
> check its adoption. People complaining that stuff is too old could be
> directed to this rolling release version and we will likely get people
> complaining that stuff moves too fast, but at least, we can't be blamed
> to ship too old softwares, that would be a user choice.

If you assume that freezes take more or less the last 25% of the
development cycle, as far as I am concerned testing _is_ already a
rolling release 75% of the time. And TBH having those last 25% of the
time as a stabilization period does not hurt anyone, on the contrary.

[toc] | [prev] | [next] | [standalone]

#8662

[Multipart message — attachments visible in raw view] — view raw

On 2016-05-20 at 07:59, Antonio Terceiro wrote:

> On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
> 
>> ❦ 19 mai 2016 16:39 GMT, Bas Wijnen <wijnen@debian.org> :
>> 
>>> Debian stable is for users who want a rock solid system.  It is
>>> out of date by the nature of how it is built.  Users who want to
>>> get the newest versions of their software should not be running
>>> stable; testing is probably better for them.
>> 
>> testing is not suitable for most people because:

>> 2. packages can disappear at any time
> 
> If they are broken. In my book that a feature and not a bug.

From a user perspective, it can be a problem, e.g. in the following
scenario:

* Package is in testing, works fine. User installs it on one or more
machines.

* Package in testing gets updated to a newer version, which is broken.

* Package gets removed from testing, because it's broken.

* User, who quite possibly never saw the broken version, wants to
install package on another machine.

From the user's perspective, what should have happened at step 3 is for
the package version available in testing to be reverted back to its last
non-broken version (whether verbatim or with a version bump over the
broken one), not for the package to have been removed entirely.

This may well not be practical as a policy, and I'm not trying to
suggest it as one, but it's an example of how broken-package removal can
be a bug rather than a feature.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#8664

Antonio Terceiro <terceiro@debian.org> writes:
> On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
>>  2. packages can disappear at any time
>
> If they are broken. In my book that a feature and not a bug.

>From the user's perspective, they are also often *not* broken. Just take
the "pandas" package as an example. The package was removed from testing
due to some RC bugs, which are now resolved. However, now the packages
do not build on many platforms, so the migration to testing fails.

For an amd64 machine (which most of the users have), the package works
fine, and from an user's view the package is just not broken. It
disappeared and he can (as long as he has no good knowledge about the
package management) not solve this. The situation gets even more
complicated when the user is not using "python3-pandas" directly, but as
a dependency of another package.

This behavious may be useful for a development platform, but for an end
user this is just inacceptable. Just think if this happens with the only
email program or web browser the user knows about.

Best regards

Ole

[toc] | [prev] | [next] | [standalone]

#8665 — testing is a tool for the release team (Re: third-party packages adding apt sources

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 20, 2016 at 02:40:56PM +0200, Ole Streicher wrote:
> This behavious may be useful for a development platform, but for an end
> user this is just inacceptable.
 
This is why we keep saying that testing is a tool for the release team
and not a suite ment for users. 

Despite that it is suitable for many users most of the time ;-)

Unstable is another suite which is very usuable for many users most of
the time, yet we only advertise it to be used by developers who can live
with breakage.

The release team needs testing. If anybody else needs a similar suite but
slightly different, go create it. It's not that this cannot be done, it
"just" needs *someone* to *do* it.

I wouldn't want us to break the release teams tool, releasing Debian is
hard enough already. 


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#8670

[Multipart message — attachments visible in raw view] — view raw

 ❦ 20 mai 2016 08:59 -0300, Antonio Terceiro <terceiro@debian.org> :

>> testing is not suitable for most people because:
>> 
>>  1. no security support
>
> That's not true. Proper security fixes will get into testing after 2
> days in unstable if everything goes right as long as the maintainer, or
> something that cares, does the work.

The fix could be blocked by a transition, by an unrelated RC bug, by a
failure to build on some architecture. And nobody will care that much
since testing is not that important until the freeze is near.

>>  2. packages can disappear at any time
>
> If they are broken. In my book that a feature and not a bug.

They can disappear due to any RC bug, even something that's not
noticeable by the user, like a FTBFS of a dependency. Would you postpone
the installation of a server until the package is available?
-- 
Instrument your programs.  Measure before making "efficiency" changes.
            - The Elements of Programming Style (Kernighan & Plauger)

[toc] | [prev] | [next] | [standalone]

#8677

On Fri, May 20, 2016 at 1:26 PM, Vincent Bernat wrote:

> testing is not suitable for most people because:
>
>  1. no security support

This can be mitigated by adding unstable to your sources.list and
using a wrapper around debsecan to automatically pull in packages from
unstable when
there are security fixes available:

https://bugs.debian.org/725934

>  2. packages can disappear at any time

This can be mitigated by adding unstable to your sources.list. The
same is true for unstable however and that can be mitigated by running
how-can-i-help frequently and migrating to new packages or putting in
some work when you see packages that are important to you are to be
removed.

These mitigations may not be suitable for everyone though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#8663

]] Bas Wijnen 

> Debian stable is for users who want a rock solid system.  It is out of date by
> the nature of how it is built.  Users who want to get the newest versions of
> their software should not be running stable; testing is probably better for
> them.

This often isn't what users want, though.  They want the newer versions
of some packages: On my server, I want a new weechat (since it has
bugfixes and features I use), I want a newer grafana (ditto).  I don't
care about having a newer version of emacs, the version in stable is
fine.  Ditto for, say, postgres.

Other users are going to care about different sets of packages, but we
all have the same «I want stable, but for $list_of_packages».

Maybe backports is what we decide is the best solution for those cases,
but maybe we can do better than that.

> > We have zero procedure in place for the following:
> > 
> >   - Totally unsupported very old version of ${FOO} in stable, maintainer
> >     isn't patching bugs, bugs are going to upstream, and upstream is
> >     annoyed Debian has out of date, perhaps insecure thing X.
> 
> Yes, this is a different problem.  We may want to shield upstream from
> bugreports for those packages somehow.

I'm not at all convinced we can shield upstreams, since users will show
up on mailing lists and IRC upstream and go «I'm trying to do $X, but it
doesn't work, and according to the online docs, it should» and after a
bit of a back and forth, it's discovered that they're running an old
version which either lacks the feature or where it's broken.

> IMO it would be good to recommend our users to file all bugs with us,
> and leave it to the maintainer to pass them to upstream.  I have
> upstreams that follow our bug tracker, which is great.  But if they
> don't, it should be up to me to decide whether the report is worth
> their time.

A lot of user interaction isn't bug reports, but rather closer to user
support.  I don't think it's reasonable for maintainers to be asked to
do all the user support that upstream does.  Even just handling bugs
well (triaging and in some cases fixing and sending patches upstream) is
a lot of work.

> > Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> > *external archives* because it's easier.
> 
> This indicates that our procedures are too hard.  That needs to be fixed.
> Maybe people from those teams are reading this and can comment on it?

No, it doesn't merely indicate that our procedures are «too hard».  I
think apt.postgresql.org exists because PostgreSQL.org themselves want
to provide a service to our common users.  We don't want to have all the
supported postgresql versions in our distro, but it's super useful for
users who need a particular version.

> > Making it hard to install a new archive will only lead to more
> > workarounds, more FAQs telling users to dismiss warnings, and more
> > upstreams hell-bent on working against us, because we keep making their
> > lives harder.
> 
> Yes.  But I'm reluctant to throw away our stable release process.  If it's not
> for everyone (and it isn't), we should be more clear about that.

I haven't seen anybody advocating throwing away our stable release
process.  So far it's mostly pointing out problems, not yet trying to
come up with solutions.  (Which is fine, we need to find out what the
problems and the pain points are before it's useful to come up with
solutions.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#8653

Paul Tagliamonte writes ("Re: third-party packages adding apt sources"):
> [cc'ing devel, since this is a rant that involves technical topics, and
>  god knows I only go on so many rants a year these days]

I think you may have only BCC'd -devel, or something.

> > Sometimes there is good reason their
> > package doesn't belong in Debian but sometimes it is more about inertia
> > in Debian or the upstream isn't aware about backports and thinks their
> > package will be stuck at a particular version forever
> 
> Frankly, I have a hell of a lot of sympathy for this.

I just wanted to say that while my own messages have been addressing a
rather different set of third-party repos, I don't really disagree
with the picture you paint.

> We have zero procedure in place for the following:

And I definitely agree with this complaint.

> Go to any mature project, they have a way to bypas the archive, and get
> the latest stable from upstream. This is a huge failure. Upstreams
> aren't becoming DDs and updating packages, dispite the fact they can
> package and maintain things.
> 
> Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> *external archives* because it's easier.

Yes.

Ian.

[toc] | [prev] | [next] | [standalone]

#8645

Daniel Pocock <daniel@pocock.pro> writes:

> b) many upstreams appear frustrated about getting their package
> officially supported in Debian.  Sometimes there is good reason their
> package doesn't belong in Debian but sometimes it is more about inertia
> in Debian or the upstream isn't aware about backports and thinks their
> package will be stuck at a particular version forever

One of the big reasons why organizations do this is because they provide
packages for stable users and want control over exactly when they ship new
packages to those users without meeting the standards for stable update
review (which are very strict).  Consider Google Chrome's packages, for
example, which are one set that use this method.

I don't think we can provide that inside Debian, at least without some
pretty significant changes to how we handle stable releases that are
contrary to some of our goals for stable.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#8646

[Multipart message — attachments visible in raw view] — view raw

On Thu, May 19, 2016 at 08:45:09AM -0700, Russ Allbery wrote:
> I don't think we can provide that inside Debian, at least without some
> pretty significant changes to how we handle stable releases that are
> contrary to some of our goals for stable.

I think I heard someone saying "PPA" or such…

;-)

(But I don't think those would be suitable for Chrome from Google.)


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#8648

Daniel Pocock writes ("third-party packages adding apt sources"):
> b) many upstreams appear frustrated about getting their package
> officially supported in Debian.  Sometimes there is good reason their
> package doesn't belong in Debian but sometimes it is more about inertia
> in Debian or the upstream isn't aware about backports and thinks their
> package will be stuck at a particular version forever

Providing a proper Debian source package is also a lot more work than
writing some kind of ad-hoc build system that spits out a .deb or
three.

> From a technical perspective, can we do more to prevent users being
> surprised by packages putting new entries in /etc/apt/sources.list.d?

IMO we should set up a registry of such organisations, and their
cryptographic keys, and at least document promises made by the
organisation about its behaviour with respect to various principles
that we might care about.

(For example, "this repo only contains packages which are dfsg-free
and come with source code"; "this repo contains packages which do not
themselves phone home"; ...)

> From an organizational perspective, can we do more to make contact with
> such upstreams and try to find ways to involve them in releasing their
> packages through official channels?  Is there any way we could gather
> data about how many upstreams do this without compromising user privacy?

Debian proper has a very high bar for inclusion.  Obviously there are
perhaps some packages which are close to suitable for inclusion, but
the vast majority of things that aren't in Debian proper are outside
it for real, nontrivial reasons (whether of technical quality of the
binaries, technical quality of the source, or political/ethical
reasons).

What we need to do is provide an easier and better way for unofficial
repositories.  That means an easy way for third party software
providers to publish repositories which it is then easy for users to
use, if the user chooses to do so.

Importantly, we need:

1. A way for the user to get good, trustworthy (ie, coming in some
   sense from Debian), information about the repository.  Including
   the identity of the organisation providing it; and some
   classification of Debian's opinion about the software in it.

2. A way for the user to reliably get the public keys on their system,
   that doesn't involve them clicking on a .deb on the public
   internet.

If we had such a thing, dealing with the admin of it would be a
nontrivial task.  It would have to be distributed.

Ian.

[toc] | [prev] | [next] | [standalone]

#8650

On 19/05/16 19:04, Ian Jackson wrote:
> Daniel Pocock writes ("third-party packages adding apt sources"):
>> b) many upstreams appear frustrated about getting their package
>> officially supported in Debian.  Sometimes there is good reason their
>> package doesn't belong in Debian but sometimes it is more about inertia
>> in Debian or the upstream isn't aware about backports and thinks their
>> package will be stuck at a particular version forever
> 
> Providing a proper Debian source package is also a lot more work than
> writing some kind of ad-hoc build system that spits out a .deb or
> three.
> 
>> From a technical perspective, can we do more to prevent users being
>> surprised by packages putting new entries in /etc/apt/sources.list.d?
> 
> IMO we should set up a registry of such organisations, and their
> cryptographic keys, and at least document promises made by the
> organisation about its behaviour with respect to various principles
> that we might care about.
> 
> (For example, "this repo only contains packages which are dfsg-free
> and come with source code"; "this repo contains packages which do not
> themselves phone home"; ...)
> 
>> From an organizational perspective, can we do more to make contact with
>> such upstreams and try to find ways to involve them in releasing their
>> packages through official channels?  Is there any way we could gather
>> data about how many upstreams do this without compromising user privacy?
> 
> Debian proper has a very high bar for inclusion.  Obviously there are
> perhaps some packages which are close to suitable for inclusion, but
> the vast majority of things that aren't in Debian proper are outside
> it for real, nontrivial reasons (whether of technical quality of the
> binaries, technical quality of the source, or political/ethical
> reasons).
> 

Do you think that if these upstreams became involved in other ways - for
example, if we proactively invited them to MiniDebConfs and other events
- we might bridge the gap to help them understand our way of thinking,
whether it is technical or otherwise?

Sure, some of them will never change, some of them have no capacity to
think long-term but there are others who simply don't quite understand
and may go the extra mile if they get to know us a little better.

> What we need to do is provide an easier and better way for unofficial
> repositories.  That means an easy way for third party software
> providers to publish repositories which it is then easy for users to
> use, if the user chooses to do so.
> 
> Importantly, we need:
> 
> 1. A way for the user to get good, trustworthy (ie, coming in some
>    sense from Debian), information about the repository.  Including
>    the identity of the organisation providing it; and some
>    classification of Debian's opinion about the software in it.
> 
> 2. A way for the user to reliably get the public keys on their system,
>    that doesn't involve them clicking on a .deb on the public
>    internet.
> 


Another thing comes to mind: making sure that even if the user
explicitly allows some other repository, they are protected from package
updates that come along and replace other things like apt itself, libc,
bash, gnupg, ...

[toc] | [prev] | [next] | [standalone]

#8652

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, May 19, 2016 at 07:15:01PM +0200, Daniel Pocock wrote:
> Another thing comes to mind: making sure that even if the user
> explicitly allows some other repository, they are protected from package
> updates that come along and replace other things like apt itself, libc,
> bash, gnupg, ...

I don't think we want to prevent that.  If they want to install a package that
does that, they can.  However, I think it is reasonable to warn them that they
should get ready for trouble when installing a package that isn't from Debian,
and especially if they install a new entry into sources.list from an external
source.

I don't see how to technically do such a thing though; the problem is that
these kind of upstreams often don't care about our (or their user's) systems
and will inject any code in their package that makes the warnings go away.

Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfugAAoJEJzRfVgHwHE61mcQAKQzjwht59J73zievxLTlqoz
QNMnmorJJb5vvx1PDwJzfqqL4rqRPu5/h9wiHjYhi+O3YM2J8W4phKxyMNIDYR1R
p+BA1CwSUuGX3/4je1QWaNpHa6IpgU9HxlUtrLNnjhJvtAuRR4PXfv15tPxsGgxi
AT5770XMSuCjNSehpC5nhp2l9HFiaRnaTa8tIENf6Bj1NrXrH/Em2/3CKbZiTkTf
S5C0IHWPTJyIYGqRALub+DiVvYd/d2ZNdFAwRW3/8nyJeBLwEkQ9BO8mNOdBHZWF
Fbvi0WJ5bBo1mcIVc9vO/4QvrFGPqxXYo8Sf+dI2O/NmzKdQ6XXwcy30HL8R/DhD
gZzhOJLnJFmUTpvqUAv1ywt9mfqNE4ed7/9ccN+4nTVHNSbxqJZyEimIi6x7dZop
dYZvdjoDgHRBFG7cBaGGH0Dqb+r0fSkP05Foxxy3ShITMzYQRPDzRPmxRxaU6ojB
Y5+GLQ3wlEMmiNsK34y1pQcJYKI5B7d+LYS1B/K5/Enkv7Z+4n8CX2AHtRMDmpHt
wQYKKaHjOktGZQonE1fF0vb4WE4otoidAyyN0jnlQDlq9aTp4OHDFcx5o8u6ppgG
LmKw7YTosFwzd37kHmH7icwvXiPHwIvHwR+9Vt/0wra/juD9Xktom2TtuA02MwIY
nPAD/aVlO95tD43+9EQP
=54DY
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#8656

Bas Wijnen writes ("Re: third-party packages adding apt sources"):
> On Thu, May 19, 2016 at 07:15:01PM +0200, Daniel Pocock wrote:
> > Another thing comes to mind: making sure that even if the user
> > explicitly allows some other repository, they are protected from package
> > updates that come along and replace other things like apt itself, libc,
> > bash, gnupg, ...
> 
> I don't think we want to prevent that.  If they want to install a
> package that does that, they can.  However, I think it is reasonable
> to warn them that they should get ready for trouble when installing
> a package that isn't from Debian, and especially if they install a
> new entry into sources.list from an external source.
> 
> I don't see how to technically do such a thing though; the problem is that
> these kind of upstreams often don't care about our (or their user's) systems
> and will inject any code in their package that makes the warnings go away.

If we provided a better, more official, way, that gave the relevant
software provider some kind of semi-approval, then we could probably
persuade the upstreams to start using it.

But I agree that playing core wars against the third party repo
packages is a really really bad idea.  It won't work.  It's a recipe
for craziness.  And it's unethical because it also amounts to playing
core wars against our users - who have, after all, probably decided
that this is what they want.

Ian.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web