On Thu, Dec 05, 2002 at 11:57:17AM -0200, Henrique de Moraes Holschuh wrote:
> 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...
>:->
> 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.
Yeah, since others talked sense into me too, I believe that I was a bit
harsh with my first reply to you. Sorry about that, realy.
Above statement about maintainers taking great pains describes exactly
why I was so suprised by the .packlist policy. I found that part
missing somewhat.
> > 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?
Yes, it is. See above. Since I started all this stuff, I'm currently
investigating how it could be done properly, and am learning quite a bit
about the build process on my way.
> > 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).
But you got my drift! The GUI stuff and unrequested rewrite of config
files was exactly what I had in mind, and YES, Debian's documentation is
excellent.
> > 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.
See above, now that I'm sure that the thing *is* discussable, I'm off to
check how to *properly* include the .packlist stuff.
Thanks so far...
--
Well, then let's give that Java-Wussie a beating... (me)
Michael Lamertz | +49 2234 204947 / +49 171 6900 310
Sandstr. 122 | [EMAIL PROTECTED]
50226 Frechen | http://www.lamertz.net
Germany | http://www.perl-ronin.de
