Bug#481129: Bug#671503: general: APT repository format is not documented
On Thu, May 17, 2012 at 3:16 PM, Michal Suchanek
<michal.suchanek@ruk.cuni.cz> wrote:
> Excerpts from Ian Jackson's message of Thu May 17 14:53:30 +0200 2012:
>> Michal Suchanek writes ("Re: Bug#671503: general: APT repository format is not documented"):
>> > Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 2012:
>> > > Could you clarify how this differs from #481129?
>> >
>> > It's 4 years later.
>> >
>> > Sorry, forgot that I filed the bug already. It's quite some time.
>> >
>> > Given there is no feedback in 4 years I guess it is futile reporting
>> > this.
>>
>> Well, it's useful to bring it up again.
>>
>> > Admittedly there is no text in social contract about using
>> > Debian-proprietary formats. And a format only defined by "apt can read
>> > that" is definitely Debian-proprietary there is no better term for that.
>>
>> Everyone agrees that it would be better if this were documented.
>> (I have struggled on occasion myself due to the lack of
>> documentation.)
>>
>> But I think the use of the word "proprietary" is going too far. It's
>> certainly a special Debian format, but that wouldn't be changed if it
>> were documented. But it's not secret and we publish at least two
>> writer implementations and one reader implementation AFAIK, with
>> proper Free licences.
>
> However, it's easier to reverse-engineer an existing repository than
> the source code so for all practical purposes it's the same as if it
> were closed source.
That is non-sense. You said yourself that the repository is not sufficient
to understand it, yet you say that it is easier to understand with it than
with looking at the source (and the various bits and pieces where parts
are documented).
Even if you don't like apt sources, debian has a lot of other tools working
with the same repository in a bunch of different languages, so choose
which you like most and you will properly find a tool in that language to
either download from repositories or to create them.
But I don't know why we are still talking here. Russ already said he would
like to have it as a subpolicy in the debian-policy. ftpmasters already said
they would accept maintaining it. Everything left is writing this goddamn
piece of documentation. So, maybe you should just write it…
If you want to be extra fancy, start a wikipage in the debian wiki,
but start typing. Go to debian-dak@l.d.o and discuss your work there.
Would be way more productive than talking about that this document is missing…
Everbody knows that. Everybody doesn't like it. Now go and fix that.
That everyone would like to have such a document but nobody has it so far
is a strong indication that the current people are busy with other stuff.
An opportunity to get involved, I would say.
>> > I'd say it's slightly discriminatory against software not part of Debian
>> > that cannot rely on getting notified when "apt can read that" silently
>> > changes, there is no document defining what apt should be able to read
>> > that software authors can rely on to interoperate with apt, one of the
>> > core Debian tools. Apt in turn relies on open standards like HTTP and
>> > FTP to interoperate with the rest of the world.
>>
>> I think this is not an appropriate use of the social contract or its
>> concepts.
>>
>> Rather than complaining that this documentation doesn't exist, how
>> about writing the document yourself ? It's not a trivial job but it
>> should be feasible by looking at the apt source code.
>
> For me it is not feasible at all.
>
> I can, of course, describe what current repositories look like or what
> the current apt code accepts.
>
> However, that has silently changed in the past and is considered apt
> feature, not a bug.
It hasn't silently changed. It was and is still the same. Your script was
just horribly wrong and older APT versions just happened to work with
that brokenness a little better. What you created with that script was NEVER
intended to work, it just happened to be working out of complete luck
(A Release file is supposed to include current data, not non-existent
data, this conclusion is reachable even without too much guessing.
Beside that this is actually documented in apt-secure and co, but that is
the problem with most of the documentation, nobody really reads it even
if it exists… which in the specific case of the Release file is even
translated to a few languages -- i am to lazy to look it up now…).
At the time you reported that bug i also told you what was wrong in that
script and how to fix it if you want to continue to use that script, so
please don't keep up the myth that we changed everything and nobody told
you why and how and what not.
If you are really that unsatisfied with apt, feel free to use something else,
we have enough tools to choose from, it not like apt would be the only
package manager in existence. It might be the most used one, but that
doesn't say anything about documentation or available manpower.
> The status was 'documented' by existing repositories which stopped
> working.
You would complain to the mechanic who fixed the oiltank in your car
that you are now no longer able to follow the oil drops back home, right?
If we want to follow that thought, the only repository which should give
any indication on how APT might work is the one created by the ftpmasters.
Actually that is not really true as APT could basically do anything,
but if it wants to keep the status 'debian native' package it better should.
And ftpmaster could basically do anything, but this would properly
make quiet a few people (a bit) angry.
Anyway: "Documented" is it absolutely not by any random repository which
just happened to sort of work because its maintainer was lucky and
thinks that "if it builds without a fatal error, it must be perfect".
Best regards
David Kalnischkies
Reply to: