Re: Debian-Perl-Policy and .packlist?
On Thu, 05 Dec 2002, Michael Lamertz wrote:
> Oh dammit, do we really have to enter these dark lands...
Apparently. Let me get my scuba suit, and a harpoon...
> On Wed, Dec 04, 2002 at 09:49:17PM -0200, Henrique de Moraes Holschuh wrote:
> > > the module which works perfectly well on, ... well, on how many platforms
> > > does perl run?
> >
> > And since when that matters? It is a bug against a DEBIAN package, for not
> > doing things 100%-correctly-and-in-the-best-possible-way for DEBIAN.
> >
> > Don't get upstream bugs and issues mixed up with Debian ones. They are
> > different sets (although not disjoint).
> > --
> > "One disk to rule them all, One disk to find them. One disk to bring
> > them all and in the darkness grind them. In the Land of Redmond
> > where the shadows lie." -- The Silicon Valley Tarot
> > Henrique Holschuh
>
> Don't you find the combination between what you say above and what's in
> your sig a bit weird sitting there side by side?
Heh.
> One of the reasons I switched to Debian was, that RedHat felt less and
> less like Unix, and more and more like, hmmm, RedHat. The reason I
> always ignored SuSE was, that they broke stuff by going their own way
> and ignoring how other systems did basic things.
Well, Debian has _always_ done things on its own way. What we _do_ try is to
make it sure we're going for the best possible solution... which might be
.packfiles AND a proper provision for their merging for core modules, btw.
That _is_ the "bad" reputation Debian has, you know. That we are quite ready
to fork upstream and do whatever we believe is right, when it cames down to
that. Most maintainers take great pains to avoid that, and do such stuff
in a way upstream is happy with, but this is not always possible.
You are not allowed to try to fix just half of the problem [and expect
others to notice it and keep silent about it] in Debian.
> And that's also the Redmond strategy. Fetch any standard, and then
> pervert it *just* a bit, so it makes switching a pain.
Debian's is: find the problems, propose and test a fix, and send it
upstream. A bit different, don't you think?
> On Debian I feel pretty safe that no weird unexpected methods of doing
> stuff are introduced.
Don't. We have "weird" methods everywhere; see update-modules, for an
example... we're no better than RedHat in that area, I'm afraid.
OTOH, we do have it all documented in Debian policy, AND we don't have GUI
things with configuration stored in weird places that keep rewriting your
config files without any proper prior notice (if we do, it is a bug), AND
anything that is auto-generated has a big "don't edit this file, see manpage
for foobar(4) instead" (or it gets a big freaking bug telling the maintainer
to fix his ways or get NMUed).
> What you're saying is basically: "I don't care that they're doing that
> for years, I enforce my way. My policy breaks their stuff? Ok, they
> let's break that other package too, because my policy is correct by my
> own definition."
Nobody said anything like this, but you. What I did say was that you will
not get away with partial solutions here, and it was pointed out that there
were possible sortcomings that need to be addressed before a formal proposal
is made.
And yes, that formal proposal can very well be "use .packfiles", but since
someone asked, you need to explain why it won't break for core modules.
Most people in Debian won't accept what upstream (or the others) do as "the
best possible way to do it" just because. Which doesn't mean they're right,
or wrong. Just that they will think about the issue first.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: