Re: sources.list brainstorm
On Sat, Jul 2, 2011 at 11:38, Paul Wise <pabs@debian.org> wrote:
> As a result of me filing #632438 (asking for mechanisms to get popcon to
> exclude packages), I discovered that you can put options in the
> sources.list lines, but they aren't documented (#632441). That led to a
Thanks for filling the reminder! Documentation of all MultiArch features
in manpages lags a bit behind the spec and a bunch of readmes…
> brainstorm about a better sources.list format on #debian-devel. If you
> were to consider a newer more readable and flexible format, please start
> discussions on the debian-user and debian-devel lists to get more ideas.
>From my point of view, if we really need a different format, it should be
a rfc822 one as we have a parser for that already. JSON, INI or XML isn't
exactly something you want to use if you need to write a parser for it, too,
to avoid depending on to much stuff…
> I mentioned that if the client-side automatic mirror selection stuff was
> to be added to apt, then a shakeup of the sources.list format might be
> in order, depending on how it is implemented.
We currently ship the infrastructure for a server-side automatic mirror
selection with the 'mirror' method. I think ubuntu wants to try to deploy
it (at least that is what they planed on the last uds), i lost track if debian
wants to play with it after Peter Palfrader did some personal tests with it.
See also http://lists.debian.org/debian-devel/2011/03/msg00491.html
It's the first time that i hear something about client-side selection through,
so i don't know what the requirements for this would be…
(and more importantly: Who is willing and/or does work on it)
> The first thing that came up was the format of the file itself. One
> developer disliked the single-line format and thought an ini or
> rfc822-like format would be better.
The only obvious advantage of a single line is that it can be
disabled by commenting out a single line. Also, it's likely that
i want to comment out a release from time to time (if i am not pin-savvy)
instead of wanting to comment out contrib or non-free.
Thats not only easier for a human being to do but also for software
working with it - APT is just the tip of the iceberg here as it doesn't
even have functionality to write these files (instead i think some
front-ends implement it on their own. python-apt can do it, too,
d-i obviously, stuff like apt-spy and and and …).
These are all not a reason for not changing it, but it should be considered
that the single line isn't a completely none-sense choice from a decade ago
and a lot of people and software are somehow used to it…
So at best search for consents by asking all the others and at the end
drop a patch here which implements it. ;)
> I also looked at how YUM does it, some interesting options there:
>
> http://www.centos.org/docs/5/html/yum/sn-yum-maintenance.html
If i understand this right, they even have a new stanza for each component,
not only for a release… ;)
You have already found the []-optionfield which is the recycled as never used
[]-vendorfield, which we have already some requests to enable some more
options. Clearly, if we go for a stanza instead, this would be a bit saner…
> # Some hypothetical future where we can install RPMs using apt
Just for the record: apt-rpm already exists and is used by some distros,
(in different versions for different rpms to make it even harder to track)
it's just that the fork happened at 0.5.something (thats before apt-security)
and is even more maintainance-only than our lovely apt here, so a merge
back is even through some features are interesting not very likely to happen
in the short- and middleterm making it even more unrealistic in the longterm.
(I would be happy if someone could prove me wrong through…)
Best regards
David Kalnischkies
Reply to: