[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]



Guillem Jover <guillem@debian.org> 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 satisfied with
> potential alternatives, etc.

At least from a Policy perspective, I don't see any obvious need to remove
the feature from dpkg regardless of the outcome of this discussion (nor do
I think that's within the scope that Policy should even consider).  dpkg
may support all kinds of things that Debian chooses not to use or even
prohibit in the archive, and I think that division is healthy and good.
dpkg is a more general tool than just Debian.

dgit is *also* a more general tool than just Debian, of course, and I can
see some reasons why the dgit maintainers may aspire to handling every
package that dpkg can handle, even ones that wouldn't be uploaded to
Debian, and thus may care about whether the feature is supported at all.
But I think that's outside the scope of Policy and could be discussed
betweeen dpkg and dgit maintainers if that's a concern.

> That Ubuntu finds it to be a problem as a Debian downstream, with these
> packages percolating into Ubuntu? Well, you could also have tried to
> argue your case to the ftp-masters and lintian maintainers, that this
> is making your life difficult, and whether they would reject packages
> with debian/patches/ubuntu.series. Or convince the maintainers in
> Debian using them that this is in fact not helping you.

> Apparently, you do not even need to do that anymore, you just need to
> get a ctte to ban them from Debian.

I'm a bit confused about why you're upset with us asking the Technical
Committee to make a decision when you're (apparently, maybe I'm
misunderstanding) fine with asking ftp-master to reject such packages.  Of
those two things, I think the Technical Committee discussion is more open,
collaborative, and accountable than asking ftp-master to reject packages!
(Indeed, if I were ftp-master, I would just bump the request to the
Technical Committee anyway, since I wouldn't want to make that sort of
decision on the basis of just the ftp-master delegation authority.)

Anyway, for whatever it's worth (and I realize and respect that I'm
probably not ever going to make you happy with forwarding any decision
from Policy to the Technical Committee, even though I feel obligated to
try anyway), the point isn't to be authoritarian.  The point is to put
this issue in front of a forum that contains several of the most senior
project members and which can bring a lot of expertise to bear on thinking
through the options, asking good questions, and clarifying the tradeoffs.

I think everyone wants to make these decisions by consensus and the best
outcome is for everyone involved in the discussion to arrive at the same
conclusion.  But for questions that reduce to asking whether something is
or isn't allowed, we do have to arrive at a decision.  Discussing it for
an extended period of time without making a decision is implicitly making
the decision to allow it, so it's just making a decision by default, but
in an awkward way that leaves everything uncertain.  I'd much rather make
that decision openly and clearly so that people understand it and can rely
on it.

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


Reply to: