Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)
On 25-04-13 10:50, Clint Byrum wrote:
> On 2013-04-24 12:43, Guillem Jover wrote:
> All of the things you mention are huge accomplishments, but the scope is
> what I am suggesting has gotten out of hand. Do we really need "a high
> level view" and "QA of the entire system" for MongoDB?
We don't need it for MongoDB, but we do need it for Debian.
The difference might seem to be minor, but it isn't.
> It is a daemon
> and some client tools. If I install it from tarball, I know this is
> shocking, but it actually works fine and doesn't interfere with anything
> else.
That's fine, great, and dandy. But it's besides the point.
I would hope that all upstream software "works fine" and "doesn't
interfere with anything else" if installed from tarball. If it doesn't,
they seriously need to check what they're doing.
But Debian packages go beyond "work fine". They are integrated. If there
are other packages out there that do similar functionality to whatever
it is that "MongoDB" does (I don't have a clue, but it doesn't matter
for this discussion; I guess it's some sort of database), then it's
reasonable to expect that a MongoDB package would need to behave
similarly to those other packages.
For a database server, this could include things like:
- making sure the data is stored in the right location in the file
system; e.g., postgresql upstream assumes all its stuff (binaries,
configuration, data files) are stored in a single directory. Given their
background (they support way more systems than we do; e.g., they also
support Windows) this makes sense, but that doesn't mean we should, too.
- If it's an SQL database, integrating everything with dbconfig-common.
This is a Debian-specific thing to make installing database-using
packages easier; it makes no sense whatsoever to push this upstream.
- ... probably others, but I'm not very fluent in packaging of database
systems.
> If it does, I will complain to upstream. My suggestion is not to
> stop packaging, but to shift focus from "make an awesome package" to
> "make an awesome upstream" that results in an automatically generated
> awesome package. Debhelper and many of the other tools definitely help
> with this, but we can do more.
Yes, we do have a guideline that says you should push improvements
upstream if and when they make sense there, and that is more often the
case than you'd think if you were just looking at the number of patches
that flow upstream.
But making a distribution is so much more than just checking licenses
and converting source into installable packages.
Take, for instance, the apache packages. If you were to just take the
upstream source, compile, and install it, then it would also Just Work.
But it wouldn't have the same flexibility that the Debian packages have.
On Debian, you can just install some libapache-mod-foo package, and due
to how the configuration files are arranged, it will simply work. This
kind of integration isn't something that can (or should!) be done
upstream; it's squarely inside the realm of what a distribution does.
The amount of such integration is part of what makes a distribution
unique; some distributions tend to do this more than others, and at one
extreme of this are Arch and Slackware, who make it a policy to ship
upstream source as pristine as possible. Debian is clearly not at that
extreme, and it should not be, IMO; the high level of integration, the
expectation that I can have from the behaviour of a package that's part
of Debian is what attracted me to Debian in the first place, and if we
ever lose that I'll probably start looking for a different distribution.
>> And all this, upstream will never be able to provide (at least not as
>> defaults), because each distribution has its own policies, some are
>> better, some are worse, and some are just different. In general I'd
>> never trust the packaging produced by an upstream for a distribution
>> they are not involved in. But most of the time there will be no such
>> packages for the desired distribution anyway.
>>
>
> Debian wants to provide end-to-end generalized tight integration. Thus
> packages lagging behind upstream. I'm suggesting that this tight
> integration ideal actually *limits* the scope of Debian.
Sometimes packages are lagging behind, yes, and that's a problem; but I
don't agree that the tight integration lies at the root of that problem.
When done right, this kind of integration consists of just a few files
inside a debian/ directory; they should not interfere with packaging a
new upstream version.
Yes, there are exceptions, and we should strive to eliminate such cases.
Sometimes this is because upstream is no longer active; sometimes this
happens because the maintainer isn't doing a good (enough?) job.
Whatever the reason, it's something we should try to fix. But just
throwing our hands up in the air and saying that we should therefore
give up on trying to integrate isn't the right way forward, I'd say.
[...]
>> Although there's been work on creating distribution-neutral specs that
>> some upstreams have picked up, there's always going to be something new,
>> the specs will just not cover all needed things, the specs might not
>> be liked by some/many people, or might not have been fully adopted by
>> all upstreams.
>>
>
> Right, and Debian maintainers can, and will keep bending over backward
> to get all the upstreams into Debian.
I'm not sure I understand what you mean here. Can you elaborate?
>>> Where Debian's efforts should be focused is on things like license
>>> verification and helping bug reports and fixes get to upstream.
>>
>> So basically, getting rid of most of the fun stuff and turning it into
>> a lawyerish play-ground and support center... I'd venture to say, not
>> the most attractive work for most people here if it was the only
>> thing to be done, which we do because we think it's important non the
>> less.
>
> I am suggesting that there are a lot of things that are much more fun
> than conforming software to Debian policy.
This feels like the wrong attitude; like somehow policy is a stick that
will come and beat you if you don't follow it. It isn't.
The goal is to make a unified, integrated distribution. Integration is
possible on many levels, but whatever way you choose to integrate, you
can't do it without some agreement on *how*, exactly, you're going to
integrate. Policy is that agreement.
Yes, it's fairly detailed, but no, it's not set in stone. Making changes
to policy, if and when that is the right thing to do, is fairly easy
(I've done so occasionally).
Getting a package to be compliant with Debian policy isn't the end goal
of what we do; instead, it's just an aid to get at the *actual* end goal
-- a well-integrated and functioning overall system. And that,
certainly, is a lot of fun.
> I'm also suggesting that
> these things don't need to happen in the context of Debian. Its not so
> much that Debian should only care about "lawyerish" things. However,
> going through those steps for people is something that I feel Debian
> uniquely cares about.
Perhaps that is true. However, I don't think that's a bad thing. If you
do, you're certainly welcome to that opinion; but in that case, I would
suggest that perhaps Debian isn't where you should spend your time (and
I don't mean that negatively; life's just too short to spend time at
things you don't like doing).
Regards,
--
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.
Reply to: