Re: Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hi Sean,
On Mon, Jun 06, 2022 at 11:08:48PM -0700, Sean Whitton wrote:
> I think this argument needs to be made more precise -- we should be
> clearer about why this particular un-uniformity is bad. I don't think
> the issue for new contributors is persuasive enough, as new contributors
> can mostly ignore source packages. It's not like, e.g., debhelper
> vs. cdbs. I haven't yet seen an argument that the lack of uniformity is
> doing anyone's work any harm comparable to the harm done to things like
> what Ian and Sam want to do.
It seems to me that Ian et al works from the premise that source
packages are an export format and that git is the truth. In a sense,
that is correct as that's what most maintainers work with.
Unfortunately, packaging repositories have very diverse workflows, lack
discoverability and miss a simple trust root. A number of people have
tried to reconcile the various workflows, but that helps only so much.
On the other hand, source packages offer a very simple trust root and
uniform interface. If I am to modify an arbitrary package (with no prior
knowledge about it), I have some options to go about it.
I can use debcheckout. For a few packages, there is no repository
declared. Yet others point to non-existent servers. Still others point
to an obsolete repository that has been moved. After checking it out, I
have a git tree of something. It may come without upstream sources (e.g.
DHG) or with upstream sources. Patches may be applied or may be not. It
may be for the version I'm looking at or including unreleased changes or
pointing at some other suite. The representation of patches in git is
another story. The source repository may provide the ability to create
pull requests. Maybe the maintainer looks at them or maybe I'll have to
send a mail to the bts. I have no chance of figuring out this mess
without investing significant amount of time.
Then I can use dgit. It is way more uniform in a lot of aspects. Its
trust root resides with the CA cartel. The resulting tree may or may not
be representing the version I'm interested in. The history may be useful
or autogenerated for my checkout as initial checkin. The Debian
maintainer may be completely ignoring this representation. Most likely,
I won't be able to send a pull request.
And then, I can apt source the package. This is really simple and has an
easy to understand trust root. It also is reproducible. Unless using a
1.0 source format, debian/source/format tells me what kind of patch
system to expect and gladly there aren't too many options. I can
concentrate on the substance of my change without being distracted by
the packaging workflow details.
Please keep in mind that this is about trade-offs. It is a question of
how we value "package ownership". If we favour the strong ownership
approach that Debian used for a long time, then yes accommodating the
needs of maintainers is paramount. If we want to lessen the concept of
ownership, embrace drive-by contributions and decentralize maintenance,
then we need a stronger focus on uniformity. I suppose that my own
opinion on this matter is fairly obvious at this point.
Annoyingly enough, 3.0 (quilt) can be abused as well by deleting the
series file and managing patch application inside debian/rules. We do
have packages doing just that.
> I agree, it's not about the benefits of the source format, we do indeed
> understand all the trade-offs by now. It's that certain ideas and
> workflows *which are not really about source packages* are made
> inconvenient or impossible if we remove this option. In other words, it
> needs to be replaced before it can be deprecated.
I admit being somewhat ignorant towards workflows, because there are
just too many for me to be bothered to learn them all. In any case, I do
take issue with the premise that workflows need to continue to work.
We're deleting packages from unstable and stop supporting unique use
cases all the time. In most cases, we could continue supporting them for
longer, but we choose not to. I hope we all agree that there are too
many competing workflows. How would you go about reducing them to a sane
number?
> Thanks for coming up with the text. I'd say that as uniformity is not
> good in itself, it would be good to have more concrete reasons for
> wanting uniformity in this case documented in this bug (not necessarily
> in the resolution text) before we add it to the ballot.
You can rephrase it as reducing complexity if that helps. It's not the
one additional source package format that is too much. It's that we
continue using all the failed experiments while adding new ones and when
some Lucas comes around and tries to clean up the mess he gets referred
to us.
I have anecdotal evidence that people find Debian's processes too
complex. Unless you closely work withing a particular packaging team
(with unified processes), onboarding people into Debian takes very long
compared to other projects.
Helmut
Reply to: