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

Re: Debian-Perl-Policy and .packlist?

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

> > 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                           |                       mike@lamertz.net
50226 Frechen                          |                 http://www.lamertz.net
Germany                                |               http://www.perl-ronin.de 

Reply to: