Bug#481129: Bug#671503: general: APT repository format is not documented
Excerpts from David Kalnischkies's message of Thu May 17 18:21:59 +0200 2012:
> 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).
No, understanding the repository (or current apt source) is not
sufficient to ensure that your repository will be readable by future apt
or that future repositories will not become unreadable by your apt
without any warning or explanation.
Both has happened.
> 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.
That would be awesome.
Maybe he just forgot to CC this bug as well?
>
> 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.
>
As said earlier, just writing a random document does not make apt not
diverging from it.
> >> > 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…).
My script did exactly what apt-secure says. Well, at least so much as
apt-secure is specific bout it. And the data was existing and well
recognized by apt so it passed all available tests.
>
> 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.
Indeed, you did.
After I reported it as a bug.
Were the format documented I would know from the start ;-)
>
> 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 all cars up to that day would leak oil enough so you could trace them
by the oil drops I would be indeed surprised.
Thanks
Michal
Reply to: