Andreas Henriksson writes:
> ## common conventions
> users/groups should have an "invalid" prefix to avoid clashes with local
> users
> - sometimes inconvenient to change username and lots of packages doesn't
> do this so should only be recommended when possible, not mandatory.
> - Debian- (co
Guillem Jover writes:
> If someone wants to see dpkg changed in some way related to this, I'd
> request the same thing I did to Ian a couple of years ago, gather input
> from derivatives and other current users, on their reasons for using it,
> or start a discussion with them on whether they'd be
Hi!
On Tue, 2018-07-31 at 17:53:50 +0200, Andreas Henriksson wrote:
> I'm going to attempt to first collect what I've picked up both from the
> previously mentioned mailinglist thread (and other similar ones) and
> what I've seen when reviewing maintainerscripts of packages in the
> archive. Hopef
On Tue, 2018-07-31 at 17:23:31 -0700, Steve Langasek wrote:
> On Wed, Aug 01, 2018 at 02:12:13AM +0200, Guillem Jover wrote:
> > I'm detaching dpkg from this, I don't see anything constructive to do
> > out if this, TBH.
>
> > If someone wants to see dpkg changed in some way related to this, I'd
>
On Wed, Aug 01, 2018 at 02:12:13AM +0200, Guillem Jover wrote:
> > I'm definitely not even going to consider removal of extraction support,
> > because that would break at least historic source unpacking. That's
> > the price of adding these kinds of features into dpkg.
> > When it comes to deprec
Processing control commands:
> reassign -1 debian-policy 3.9.8.0
Bug #850156 [dpkg-dev, debian-policy] Please firmly deprecate vendor-specific
series files
Bug reassigned from package 'dpkg-dev, debian-policy' to 'debian-policy'.
Ignoring request to alter found versions of bug #850156 to the same
Control: reassign -1 debian-policy 3.9.8.0
On Mon, 2018-07-30 at 06:15:42 +0200, Guillem Jover wrote:
> In any case, I discussed this in a private mail interchange with Ian
> a couple of years ago (AFAIR). My reply back then was that I don't
> personally feel very strongly about the feature, that
On Tue, 31 Jul 2018 at 17:53:50 +0200, Andreas Henriksson wrote:
> previously created users should *not* (ever) be removed
There has been a suggestion in the past that these users should be locked
on package removal and unlocked on reinstallation, as implemented in
(for example) openarena-server.
Addressing just this aside:
Agustin Henze writes:
> Thanks for that :), anyway it'd be good accepting MR on salsa and having
> the discussion there. But it's a matter of team preferences of course.
Both the BTS and Salsa are workable, both communication paradigms are used
successfully by other
Hi,
This is my attempt to unlock the progress on this issue.
I'm going to attempt to first collect what I've picked up both from the
previously mentioned mailinglist thread (and other similar ones) and
what I've seen when reviewing maintainerscripts of packages in the
archive. Hopefully others ca
Hi Sean,
On 07/30/18 04:07, Sean Whitton wrote:
[...]
>> Hi, I've tried sending this change through salsa but it seems to be disabled
>> the option for merge requests.
>
> Yes, there is a process for changing Policy that usually involves
> discussion, so we request patches in the BTS. This has c
11 matches
Mail list logo
