Abhishek Dasgupta wrote:
2009/5/22 Allan McRae <al...@archlinux.org>:
I am very much against adding _unnecessary_ fields to PKGBUILDs... If
these are not needed by makepkg or pacman, they should only be comments. It
is going to take a lot of convincing for me to think otherwise.
As long as the information in # Maintainer tags and the web interface
is the *same*, there is no problem.
What is required is an easily accessible database of current maintainers
for each package. It's always best to have as much information available
in easily downloadable form. One way (and there can be numerous
different ways of doing this) is to put this in the PKGBUILD in a parseable
form -- the reason for a bash array with the username:
- makes it easily parseable by bash scripts
- putting only the username and no other extraneous information
as email etc can change.
- ignored by makepkg as it does not recognise it (and doesn't need to)
- has no effect on the binary
As an example consider the *files.db.tar.gz stuff. Before that if one wanted
to check the filelist of a particular package, one would need to download
that particular package and check out its contents. Now, the files database
is put in an easily accessible location which enables programs like pkgfile
to access and make use of that information.
While this information could have been put as a kind of API (like the AUR
JSON interface) that would have reduced usability for users who would like
to view a filelist offline.
Currently there is no _simple_ way for scripts of finding the maintainer of a
given package in the official repositories. The only way is to parse the webpage
which is hackish and certainly not KISS. An abs (or even svn) checkout does not
help since there is no necessity that the Maintainer tag in the PKGBUILD and the
maintainer listed in the web interface is the same; which just makes
the Maintainer
tag in the PKGBUILD totally irrelevant since one has to check the web interface
anyway.
All this was discussed in the arch-dev-public thread I mentioned a few
posts back.
At that time, most people seemed to agree that this was a good idea but
nothing came of it.
So, to disown a package from the official repos would no longer require
just clicking "orphan" but unsetting the maintainer flag in SVN/CVS.
And adopting would require adding to the maintainer flag rather than
just clicking "adopt". Given the majority of packages don't even have
the motivation to add ChangeLogs, this extra layer of annoyance to take
over the maintaining of a package just does not seem appealing. This is
why I see no point in discussing this because in practice people will
not change the maintainer package until they do an update/rebuild at
which point they should change the maintainer line anyway...
Allan