The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Interesting dpkg issue, plus thoughts...

The reason I bring this to the private list, rather than taking the
discussion to the developer's list, is that I want to discuss the way
dpkg/dselect has been treated, and point out some attitude issues we
should deal with.

I came to this point from discovering a bug. I built a fresh installed
1.3.1 "standard" system on a "spare" 300 meg partition. On both this new
system and my old one, /home is a mounted partition, and /Debian
is the mount point for the partition containing the packages that I
maintain. This makes it very easy to move my accounts and packages between
systems. I have been having a problem getting a particular version of
psutils to maintain its existance on the archive at master, and needed to
upload the old version, yet again, with only a change to the distribution
targets. I added the target to the changelog and rebuilt the package. 

The problem came when the build failed telling me it couldn't chown the
substvars file because it didn't exist. (it was there, of course) I
rebooted into the old development system and the packages built fine. Both
the new and the old systems have the same version of dpkg (1.4.0.8) so
that isn't the problem.

As I said before, this isn't an attempt to get help with a technical
problem. What I want to point out is: I could have simply assumed that
there was a problem with dpkg when I got the error. These kinds of errors
have been reported about dpkg before and it would have been the "natural"
response. My attitude about dpkg seems to be markedly different than many
in the group. When dpkg doesn't work for me, my first response is to
determine what it is that I am doing wrong, not what it is that dpkg is
doing wrong.

Several months ago there was a rash of "dpkg-buildpackage will not build
my package" complaints that tended to get lodged against dpkg-source and
the constraints on directory contents at build time. I had run into those
issues when I was converting my packages and had, simply, figured out what
I was doing wrong and fixed it to work the way dpkg expected to see it.

I don't mean to make this an argument against debmake (although I have a
fundimental objection to this package) but I do feel compelled to point
out that it was conceived as a method of removing the need to deal with
the source package restrictions. The attempt to provide the maintainer
with a tool that would make many packaging decissions automatically,
although intended to make the maintainer's life easier, has actually
created more general packaging problems of its own.

The problem that it presents comes from the fact that debmake problems
are preceived as dpkg problems because that's where they appear (during
package creation). New package maintainers, encouraged to use debmake to
"help" them build their packages, submit bug reports against dpkg when it
doesn't work. The problem this creates comes from the fact that debmake
becomes the "de facto" defining influence on dpkg. Many of the changes in
dpkg that have been made, as a result, are to make it conform to the way
debmake percieves the package system "aught" to work.

Again, to try to make my point clear, I am asking that we change our
attitude about "The Source Package Format". Work toward making packages
that work within that defined structure, rather than trying to make the
structure conform to our own personal vision of what the package system
"aught" to be like. The number of packages that can't be re-built from
their source constituents, using 'dpkg-source -b', appear to be
increasing. We need a much more uniform application of the standard than
what is currently in operation.

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .