[aur-general] changing the status of the maintainer field
Many packages in Arch don't have Maintainer tags in their PKGBUILDs (around 345 last time I checked). Also quite a few the PKGBUILDs are not updated by the current maintainer. It is better to do away with maintainer tags altogether, since their functionality can be obtained from the web interface itself. Another alternative which I prefer (and which was discussed a while back) is to elevate the maintainer tag to a proper *required* tag which would be parsed by the Django frontend to update the maintainer list. -- Abhishek
Hey There, I've packaged 11 packages upto now and the reason why I don't choose to use the Maintainer tag but the Contributor tag is that AUR Packaging Standards says: When building packages for Arch Linux, you should adhere to the package guidelines below, especially if you would like to contribute your new package to Arch Linux. as the first sentence. The word "contribute" is in bold which always made me think that I'm not maintaining the package but I'm contributing the distro. Hope this helps to understand a user point of view. Cheers.. Alper KANAT <alperkanat@raptiye.org> Abhishek Dasgupta yazmış:
Many packages in Arch don't have Maintainer tags in their PKGBUILDs (around 345 last time I checked). Also quite a few the PKGBUILDs are not updated by the current maintainer.
It is better to do away with maintainer tags altogether, since their functionality can be obtained from the web interface itself.
Another alternative which I prefer (and which was discussed a while back) is to elevate the maintainer tag to a proper *required* tag which would be parsed by the Django frontend to update the maintainer list.
On Thu, 21 May 2009 12:58:54 +0300 Alper KANAT <tunix@raptiye.org> wrote:
Hey There,
I've packaged 11 packages upto now and the reason why I don't choose to use the Maintainer tag but the Contributor tag is that AUR Packaging Standards says:
When building packages for Arch Linux, you should adhere to the package guidelines below, especially if you would like to contribute your new package to Arch Linux.
as the first sentence. The word "contribute" is in bold which always made me think that I'm not maintaining the package but I'm contributing the distro.
Hope this helps to understand a user point of view.
Cheers..
Alper KANAT <alperkanat@raptiye.org>
The terminology and use was discussed a couple of weeks ago and what was agreed on is pretty much: Use maintainer if you maintain a package (and when you're the initial author of the PKGBUILD? at least that's how I do it) Use contributor for former maintainers or to attribute help you received. Regards, Philipp
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case? Alper KANAT <alperkanat@raptiye.org> hollunder@gmx.at yazmış:
On Thu, 21 May 2009 12:58:54 +0300 Alper KANAT <tunix@raptiye.org> wrote:
Hey There,
I've packaged 11 packages upto now and the reason why I don't choose to use the Maintainer tag but the Contributor tag is that AUR Packaging Standards says:
When building packages for Arch Linux, you should adhere to the package guidelines below, especially if you would like to contribute your new package to Arch Linux.
as the first sentence. The word "contribute" is in bold which always made me think that I'm not maintaining the package but I'm contributing the distro.
Hope this helps to understand a user point of view.
Cheers..
Alper KANAT <alperkanat@raptiye.org>
The terminology and use was discussed a couple of weeks ago and what was agreed on is pretty much:
Use maintainer if you maintain a package (and when you're the initial author of the PKGBUILD? at least that's how I do it)
Use contributor for former maintainers or to attribute help you received.
Regards, Philipp
On Thu, 21 May 2009 16:31:17 +0300 Alper KANAT <tunix@raptiye.org> wrote:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
Maintainer, the one that had it before you is a contributor now, you maintain it, you are the maintainer.
2009/5/21 Alper KANAT <tunix@raptiye.org>:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance. -- Abhishek
On Thu, 21 May 2009 19:07:03 +0530 Abhishek Dasgupta <abhidg@gmail.com> wrote:
2009/5/21 Alper KANAT <tunix@raptiye.org>:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance.
email addresses can change and be off, the tag in the PKGBUILD rarely contains the username but the realname is mostly the same, all provided a new maintainer didn't forget to add his credentials to the PKGBUILD. So yeah, the information is almost always different to some degree. But: what must be the same? I realise that it would be nice if it was the same. Philipp
2009/5/21 <hollunder@gmx.at>:
email addresses can change and be off, the tag in the PKGBUILD rarely contains the username but the realname is mostly the same, all provided a new maintainer didn't forget to add his credentials to the PKGBUILD. So yeah, the information is almost always different to some degree.
But: what must be the same? I realise that it would be nice if it was the same.
A discussion on similar lines took place a while back but died out: http://www.archlinux.org/pipermail/arch-dev-public/2008-September/007835.htm... -- Abhishek
We really need to clarify this once and for all because this comes up at least once a month it seems. I think most people have agreed to the following definitions, which match their plain English meaning: Maintainer: The person who maintains the package currently, i.e. the person who is responsible for keeping the package up-to-date and for handling any bugs in the package such as missing dependencies etc. Contributor: Someone who has previous contributed to the package, e.g. previous maintainers, people who have submitted modifications of the build function or dependency array, people who have contributed icons, install scripts and local sources. No distinction should be made between official packages and AUR packages regarding these definitioins. Maintaining an AUR package requires the same effort as the official package and the maintainer is just as relevant. I have no idea why someone at some point decided that official packages are "special" and that those who maintain them are also "special". The current maintainer should be readily identifiable so that users know whom to contact when issues with the package arise. This is best left to the web interface in my opinion because it is always up-to-date, whereas a field in the PKGBUILD will not get updated when a package is orphaned. The ideal would be to have a simplified API to the website so that it would be trivial to retrieve the current maintainer using a local script/program. The AUR has a json interface which is perfect for this. Hopefully the official repos will get this too with the coming changes, but I don't actually know what they're going to do (although I have sumitted a feature request for a json interface to the official repos on flyspray... I think the response was that it will get implemented later). All articles in the wiki need to be updated to reflect this so that people can stop citing outdated pages as arguments for doing it differently. I've updated one page previously but this seems to be spread all over the place.
On Thu, 2009-05-21 at 16:42 +0200, hollunder@gmx.at wrote:
On Thu, 21 May 2009 19:07:03 +0530 Abhishek Dasgupta <abhidg@gmail.com> wrote:
2009/5/21 Alper KANAT <tunix@raptiye.org>:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance.
email addresses can change and be off, the tag in the PKGBUILD rarely contains the username but the realname is mostly the same, all provided a new maintainer didn't forget to add his credentials to the PKGBUILD. So yeah, the information is almost always different to some degree.
But: what must be the same? I realise that it would be nice if it was the same.
Philipp
What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors?
On Fri, May 22, 2009 at 1:39 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On Thu, 2009-05-21 at 16:42 +0200, hollunder@gmx.at wrote:
On Thu, 21 May 2009 19:07:03 +0530 Abhishek Dasgupta <abhidg@gmail.com> wrote:
2009/5/21 Alper KANAT <tunix@raptiye.org>:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance.
email addresses can change and be off, the tag in the PKGBUILD rarely contains the username but the realname is mostly the same, all provided a new maintainer didn't forget to add his credentials to the PKGBUILD. So yeah, the information is almost always different to some degree.
But: what must be the same? I realise that it would be nice if it was the same.
Philipp
What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors?
Oh boy we just discussed this weeks ago, like a month or so. Even I though in send another e-mail remembering to _some people_ about how the things should be with the maintainer tag (the maintainer tag with my name were removed in several packages and I wasn't added as a contributor), but I won't complain about it, because for me it doesn't matter, but I think that several people would like to preserve their names on PKGBUILD that they dedicated sometime. IMHO that discussion [0] should be enough, any dev to make that discussion as the *official* way? [0] http://www.archlinux.org/pipermail/aur-general/2009-April/004386.html -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
On Fri, 2009-05-22 at 18:46 +1930, Angel Velásquez wrote:
On Fri, May 22, 2009 at 1:39 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On Thu, 2009-05-21 at 16:42 +0200, hollunder@gmx.at wrote:
On Thu, 21 May 2009 19:07:03 +0530 Abhishek Dasgupta <abhidg@gmail.com> wrote:
2009/5/21 Alper KANAT <tunix@raptiye.org>:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance.
email addresses can change and be off, the tag in the PKGBUILD rarely contains the username but the realname is mostly the same, all provided a new maintainer didn't forget to add his credentials to the PKGBUILD. So yeah, the information is almost always different to some degree.
But: what must be the same? I realise that it would be nice if it was the same.
Philipp
What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors?
Oh boy we just discussed this weeks ago, like a month or so.
Even I though in send another e-mail remembering to _some people_ about how the things should be with the maintainer tag (the maintainer tag with my name were removed in several packages and I wasn't added as a contributor), but I won't complain about it, because for me it doesn't matter, but I think that several people would like to preserve their names on PKGBUILD that they dedicated sometime.
IMHO that discussion [0] should be enough, any dev to make that discussion as the *official* way?
[0] http://www.archlinux.org/pipermail/aur-general/2009-April/004386.html
I only send that email to show that this type of discussion is tenious at best. I look at the Maintainer tag as the "Contact person" only. The other tag I can do without (my opinion only) but I understand why people would like to maintain their names there as well. Looks like you need a Maintainer tag for the Contributor tag......what would that tag be called?
On Fri, May 22, 2009 at 3:32 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On Fri, 2009-05-22 at 18:46 +1930, Angel Velásquez wrote:
On Fri, May 22, 2009 at 1:39 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On Thu, 2009-05-21 at 16:42 +0200, hollunder@gmx.at wrote:
On Thu, 21 May 2009 19:07:03 +0530 Abhishek Dasgupta <abhidg@gmail.com> wrote:
2009/5/21 Alper KANAT <tunix@raptiye.org>:
And what if I adopted a package from someone? Am I a Contributor or a Maintainer on that case?
In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance.
email addresses can change and be off, the tag in the PKGBUILD rarely contains the username but the realname is mostly the same, all provided a new maintainer didn't forget to add his credentials to the PKGBUILD. So yeah, the information is almost always different to some degree.
But: what must be the same? I realise that it would be nice if it was the same.
Philipp
What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors?
Oh boy we just discussed this weeks ago, like a month or so.
Even I though in send another e-mail remembering to _some people_ about how the things should be with the maintainer tag (the maintainer tag with my name were removed in several packages and I wasn't added as a contributor), but I won't complain about it, because for me it doesn't matter, but I think that several people would like to preserve their names on PKGBUILD that they dedicated sometime.
IMHO that discussion [0] should be enough, any dev to make that discussion as the *official* way?
[0] http://www.archlinux.org/pipermail/aur-general/2009-April/004386.html
I only send that email to show that this type of discussion is tenious at best.
I look at the Maintainer tag as the "Contact person" only. The other tag I can do without (my opinion only) but I understand why people would like to maintain their names there as well.
Looks like you need a Maintainer tag for the Contributor tag......what would that tag be called?
According the last thread, we agreed that the past maintainers will became *contributors*, so.. If I was maintainer of X package and I left the crew, the guy who will pick the package should take the "maitainer" tag, and change my old maintainer tag and put my name as a contributor. As I said, I don't really care about this, it's ok for me, but seems that some people don't follow that rule, the point of the last discussion was to clarify the rule and start to applying.. and seems that the discussion was forgotten :(. -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Baho Utot <baho-utot@columbus.rr.com> wrote:
What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors?
I'll be honest: I rolled my eyes when I read that. If you began to independently maintain all of those packages (update them yourself, modify the PKGBUILDs, etc) then you would be the "maintainer" to anyone retrieving them from you and you would be expected to deal with any errors arising from what you changed. If you do not distribute them, then "maintainer" makes no sense at all. If you simply copy the PKBUILDs from abs occasionally without adding your own modifications, then you're not really a maintainer of the PKGBUILD, but if you decide to distribute binary versions yourself then you would be the maintainer of those.
On Fri, 2009-05-22 at 06:47 +0200, Xyne wrote:
Baho Utot <baho-utot@columbus.rr.com> wrote:
What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors?
I'll be honest: I rolled my eyes when I read that.
Then I accomplished what I set out to do, That is those tags really are not that important. I compile all my packages used for the system cpu, I start with the install cd and compile base then on to the ones I need for a "working system".
If you began to independently maintain all of those packages (update them yourself, modify the PKGBUILDs, etc) then you would be the "maintainer" to anyone retrieving them from you and you would be expected to deal with any errors arising from what you changed. If you do not distribute them, then "maintainer" makes no sense at all. If you simply copy the PKBUILDs from abs occasionally without adding your own modifications, then you're not really a maintainer of the PKGBUILD, but if you decide to distribute binary versions yourself then you would be the maintainer of those.
BAH! ...and again, BAH! It is a comment people... just a comment. makepkg and pacman don't care about it and nor should anyone else! Allan
On Sat, May 23, 2009 at 12:25 AM, Allan McRae <allan@archlinux.org> wrote:
BAH! ...and again, BAH!
It is a comment people... just a comment. makepkg and pacman don't care about it and nor should anyone else!
Allan
Exactly, I don't care about it, but there are people who care about that, why? don't know, i guess, some people would like to know that they contributes or contributed :P. /* But seeing this in a technical way, the PKGBUILD should have a field (or a _useless for somepeople_ comment) with the name of the responsible of this work, at least for send e-mails to the maintainer (even if he/she will ignore it as always happens) for asking features, or reporting bugs (even if the bt exist and even if the people and maintainers are careless about it). */ # Just my opinion, comments are useful ;P -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Allan McRae wrote:
BAH! ...and again, BAH!
It is a comment people... just a comment. makepkg and pacman don't care about it and nor should anyone else!
Allan
Hello. Oops, yes is a comment but... two things: 1) Technical purposes: Having a "# Maintainer" comment line can provide a simple way to shell scripts to identify the maintainer, that in many cases the maintainer != packager. (pacman -Qi) This help in many cases, for example reporting a "mass change/rebuild/bug/feature/etc/random". 2) Ethical: While many of the PKGBUILD are trivial changes to the PKGBUILD.proto, beyond this, which made this PKGBUILD took some maintenance time of work, and giving a kind of support for it. So, I think it is important that this be retained. My two cents ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
2009/5/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
1) Technical purposes: Having a "# Maintainer" comment line can provide a simple way to shell scripts to identify the maintainer, that in many cases the maintainer != packager. (pacman -Qi) This help in many cases, for example reporting a "mass change/rebuild/bug/feature/etc/random".
2) Ethical: While many of the PKGBUILD are trivial changes to the PKGBUILD.proto, beyond this, which made this PKGBUILD took some maintenance time of work, and giving a kind of support for it. So, I think it is important that this be retained.
I started the thread to revive the idea of having a separate maintainer field for the official repositories which could be parsed by scripts to update the web interface, instead of using the web interface to change the maintainer as is done currently. This of course does not apply to the AUR and the question of Maintainer vs Contributor tag (already discussed before many times) is irrelevant here. Currently a dev/TU has to go to the package page and click "Adopt". Also he/she has to update the Maintainer tag accordingly to match it with the web interface which is often not done. If the maintainer tag was a proper field like maintainer=(username) then to adopt the package, all one would need to do is change the value of the maintainer variable and commit to trunk. The web interface would pick the changes from trunk and update itself. This would make the maintainer tag more relevant and easier to parse by scripts. This does not apply to the AUR since everything depends on the web interface there. IMO, the official repositories should have their metadata independent of the web interface, in the PKGBUILDs if possible. If this change is implemented, then one would not need to visit the web interface for such a common task. -- Abhishek
The problem is, most people don't get the following part: "This does not apply to the AUR" It has been evident over and over again that the issue was mainly repository- and interface-related, but it has been overhyped into being something that concerns the New World Order.
Am Fri, 22 May 2009 14:55:43 +1000 schrieb Allan McRae <allan@archlinux.org>:
BAH! ...and again, BAH!
It is a comment people... just a comment. makepkg and pacman don't care about it and nor should anyone else!
On the one hand I somehow agree with people, who don't care too much about these tags, on the other hand I agree with people, who think, they are quite important. Even if I've somehow mistaken both tags in the past and put me as a contributor instead of a maintainer in my PKGBUILDs - I will change this some time -, I agree, that Maintainer should contain the current maintainer, and that Contributor should contain the previous Maintainers or people, who sent patches for the PKGBUILD to the maintainer. I think these tags - at least the Maintainer tag - are quite important, because a user should be able to easily find out, who has written the PKGBUILD and whom to contact, if there's an issue with the PKGBUILD. I'm not sure, if this should be realised as an obligatory field or a comment. With a field the maintainer is forced to add his name and e-mail address to the PKGBUILD, and this is checked by makepkg or pacman. Comments are more flexible, so that more maintainers and contributors can be added to the PKGBUILD. In this case the PKGBUILD can be parsed by AUR - it's already done anyway - when a package is uploaded to AUR. If the Maintainer tag is missing the package will be rejected and the maintainer, who tries to upload it, gets a corresponding message. Nevertheless I think, there's another point. Aren't the PKGBUILDs licensed under the GPL? As far as I know, this would mean, that every current and previous Maintainer has to be mentioned in the PKGBUILD anyway. Heiko
2009/5/22 Heiko Baums <lists@baums-on-web.de>:
Comments are more flexible, so that more maintainers and contributors can be added to the PKGBUILD.In this case the PKGBUILD can be parsed by AUR - it's already done anyway - when a package is uploaded to AUR.
No, it isn't; no script parses the Maintainer or Contributor tags since they are just comments and in quite a few cases have incorrect maintainers listed.
Nevertheless I think, there's another point. Aren't the PKGBUILDs licensed under the GPL?
I've no idea about this. -- Abhishek
Yeah, can we get back to Abhishek's topic please? I think I agree with his thinking: - Make the maintainer a proper singular bash variable string - Make the contributors a praper bash array - Let the web interface hold onto its own metadata (I don't think anyone wants the web interface editing PKGBUILDs) - Possibly rename maintainer to owner and keep contributors contributors - Or if more clear, rename maintainer to current_maintainer and contributors to past_maintainers That should clear everything up and prevent further discussion. -AT
On Fri, May 22, 2009 at 08:45, Andrei Thorp <garoth@gmail.com> wrote:
Yeah, can we get back to Abhishek's topic please?
I think I agree with his thinking: - Make the maintainer a proper singular bash variable string - Make the contributors a praper bash array -1. This is totally unneeded. As Allan said, it doesn't matter at all. I see it purely as crediting previous workers in the case of Contributor, and in the case of Maintainer, it supplies the contact info more easily than the web interface.
On Fri, May 22, 2009 at 8:57 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Fri, May 22, 2009 at 08:45, Andrei Thorp <garoth@gmail.com> wrote:
Yeah, can we get back to Abhishek's topic please?
I think I agree with his thinking: - Make the maintainer a proper singular bash variable string - Make the contributors a praper bash array -1. This is totally unneeded. As Allan said, it doesn't matter at all. I see it purely as crediting previous workers in the case of Contributor, and in the case of Maintainer, it supplies the contact info more easily than the web interface.
What's so -1y to crediting past contributors? But yeah, sure, can keep that as a comment and have the "owner" bash string or whatever. -AT
On Fri, May 22, 2009 at 09:01, Andrei Thorp <garoth@gmail.com> wrote:
What's so -1y to crediting past contributors? But yeah, sure, can keep that as a comment and have the "owner" bash string or whatever.
-AT
Nothing, I'm just against putting it into a bash variable. It's not needed, the current method is fine. Stupid people will remove past contributors, but making it a bash variable doesn't help with that problem
Andrei Thorp wrote:
Yeah, can we get back to Abhishek's topic please?
I think I agree with his thinking: - Make the maintainer a proper singular bash variable string - Make the contributors a praper bash array - Let the web interface hold onto its own metadata (I don't think anyone wants the web interface editing PKGBUILDs) - Possibly rename maintainer to owner and keep contributors contributors - Or if more clear, rename maintainer to current_maintainer and contributors to past_maintainers
That should clear everything up and prevent further discussion.
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. Allan
2009/5/22 Allan McRae <allan@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. -- Abhishek
Abhishek Dasgupta wrote:
2009/5/22 Allan McRae <allan@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
Another thing that you guys probably don't care too much about is the fact that -Qi -ing a package that you have installed will not list the Maintainer for packages from AUR. I think that's another good place to be able to list at maintainer, even if the maintainer isn't a TU. Also, isn't there something kind of terrible about the fact that CVS/SVN, AUR web, and comments all track a bit of information separately and in different ways? Sorry if there are things I misunderstand here. -AT
Andrei Thorp wrote:
Another thing that you guys probably don't care too much about is the fact that -Qi -ing a package that you have installed will not list the Maintainer for packages from AUR.
Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The "Packager: " field in the output is the name + email of the person who last built the package, and this is not necessarily the maintainer. Case in point: "pacman -Si curlftpfs". Don't rely on "Packager:" from -Qi or -Si. Yes, a "Maintainer:" field in -Qi or -Si output would be nice.
Also, isn't there something kind of terrible about the fact that CVS/SVN, AUR web, and comments all track a bit of information separately and in different ways?
It is bad, but unfortunately, I think that every distro has this problem to a certain extent. Not sure what the solution is. Regards, -- Chris PS. This thread is at least convincing me to *think about* updating the # Maintainer comment in my adopted packages!
On Fri, May 22, 2009 at 12:34 PM, Chris Brannon <cmbrannon@cox.net> wrote:
Andrei Thorp wrote:
Another thing that you guys probably don't care too much about is the fact that -Qi -ing a package that you have installed will not list the Maintainer for packages from AUR.
Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The "Packager: " field in the output is the name + email of the person who last built the package, and this is not necessarily the maintainer. Case in point: "pacman -Si curlftpfs". Don't rely on "Packager:" from -Qi or -Si. Yes, a "Maintainer:" field in -Qi or -Si output would be nice.
Ah, okay, thanks. -AT
Am Fri, 22 May 2009 11:34:38 -0500 schrieb Chris Brannon <cmbrannon@cox.net>:
Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The "Packager: " field in the output is the name + email of the person who last built the package,
But only, if the packager has set the PACKAGER variable in his /etc/makepkg.conf. And I think I can remember, that not every packager (dev or TU) has set this correctly. Heiko
On Sat, May 23, 2009 at 2:17 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Fri, 22 May 2009 11:34:38 -0500 schrieb Chris Brannon <cmbrannon@cox.net>:
Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The "Packager: " field in the output is the name + email of the person who last built the package,
But only, if the packager has set the PACKAGER variable in his /etc/makepkg.conf. And I think I can remember, that not every packager (dev or TU) has set this correctly.
Heiko
Actually, you can export an env var with the value of that.. i.e: PACKAGER="Angel 'angvp' Velasquez" makepkg But now talking about the topic, you can also set the "Maintainer" flag with an env var and adding it to the .PKGINFO (I thought Andrei Thorp suggested this anyway) and past maintainers can be parsed in another .PKGINFO Field. This will need modifications of the makepkg script (and adding this to pacman in the -i option), but I think this is a good solution, for having the *actual* maintainer with -Qi or -Si. In code the thing will be like: MAINTAINER="Angel 'angvp' Velasquez" makepkg And then the makepkg will do these new jobs: 1.- Add the value of the env var MAINTAINER as the current maintainer 2.- Add the value of the env var MAINTAINER (if the value isn't in the array) to an array of pasts_maintaners to the .PKGINFO .. Note 1: If the MAINTAINER var wasn't set it will use the value of PACKAGER if isn't empty, or the classical "None" in case both vars are empty Note 2: Because is annoying to set the name everytime you will build a package that you maintain, you can add this var in something like .bashrc or on a script, BUT if you are building a package from another tu/dev (cause he asked the favour to you or something like), you should have to set it with the value of the *actual* maintainer with the ugly way: MAINTAINER="John Doe <foo@bar.com>" makepkg Note 3: to see past maintainers you should have the unpack the packages and see it on the .PKGINFO file, (because in my opinion, adding this information to -i is too much) Note 4: there are a web interface which actually parse the value of PACKAGER on the .PKGINFO [1] This Isn't something hard to do at all .. but I know that many people wouldn't like it this idea :/, actually I have to say, for me will be the same to implement or not this solution. [1] http://www.archlinux.de/?page=Packagers -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
2009/5/22 Angel Velásquez <angvp@archlinux.com.ve>:
Actually, you can export an env var with the value of that..
i.e: PACKAGER="Angel 'angvp' Velasquez" makepkg
But now talking about the topic, you can also set the "Maintainer" flag with an env var and adding it to the .PKGINFO (I thought Andrei Thorp suggested this anyway) and past maintainers can be parsed in another .PKGINFO Field. This will need modifications of the makepkg script (and adding this to pacman in the -i option), but I think this is a good solution, for having the *actual* maintainer with -Qi or -Si.
In code the thing will be like:
MAINTAINER="Angel 'angvp' Velasquez" makepkg
And then the makepkg will do these new jobs:
1.- Add the value of the env var MAINTAINER as the current maintainer 2.- Add the value of the env var MAINTAINER (if the value isn't in the array) to an array of pasts_maintaners to the .PKGINFO ..
Note 1: If the MAINTAINER var wasn't set it will use the value of PACKAGER if isn't empty, or the classical "None" in case both vars are empty
Note 2: Because is annoying to set the name everytime you will build a package that you maintain, you can add this var in something like .bashrc or on a script, BUT if you are building a package from another tu/dev (cause he asked the favour to you or something like), you should have to set it with the value of the *actual* maintainer with the ugly way:
MAINTAINER="John Doe <foo@bar.com>" makepkg
Note 3: to see past maintainers you should have the unpack the packages and see it on the .PKGINFO file, (because in my opinion, adding this information to -i is too much)
Note 4: there are a web interface which actually parse the value of PACKAGER on the .PKGINFO [1]
This Isn't something hard to do at all .. but I know that many people wouldn't like it this idea :/, actually I have to say, for me will be the same to implement or not this solution.
[1] http://www.archlinux.de/?page=Packagers
-- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Noone is going to do this if it were implemented, which I really don't think it needs to be.
Noone is going to do this if it were implemented, which I really don't think it needs to be.
Dude, two things: 1.- Instead of say "no one is going to do this ..." try to implement something better for the requirement of Abhishek, if you are not agree with the requirement is other subject, but if you are agree with the requirement, then instead of not aproving other solutions, try to think in one and propose it. 2.- You don't have to quote the entire mail that I sent (with the signature included). Have you ever used mailing lists before? -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
2009/5/23 Angel Velásquez <angvp@archlinux.com.ve>:
But now talking about the topic, you can also set the "Maintainer" flag with an env var and adding it to the .PKGINFO (I thought Andrei Thorp suggested this anyway) and past maintainers can be parsed in another .PKGINFO Field. This will need modifications of the makepkg script (and adding this to pacman in the -i option), but I think this is a good solution, for having the *actual* maintainer with -Qi or -Si.
Adding the Maintainer field to .PKGINFO has a few problems: - This makes this quite complicated, needing changes to both makepkg and pacman. - The information gets outdated and there should be only _one_ easily accessible information source about the current maintainer which is retrievable by scripts. For example, if you build a package which is not updated often; and after a few months you orphan it and it's picked up by someone else, it will not be visible to the user when the user does a pacman -Qi; that's why it's better IMO to keep this sort of information only in the PKGBUILDs. Of course, as Allan said, there might not be enough motivation to change the maintainer field in the PKGBUILD if one wishes to adopt a new package. I suppose though, that it would be easy to write a script to do such things automatically. Assuming we have one maintainer for each package, this script (not fully fleshed out, but you get the idea) should work: #!/bin/sh # adopt: adopt a package from the repositories # Change this to wherever you keep your full/partial SVN checkout. if [! -f /etc/makepkg.conf ]; then echo "adopt: no makepkg.conf found!" exit 1 fi source /etc/makepkg.conf if [ -z $MAINTAINER ]; then echo "adopt: Please set the MAINTAINER variable in /etc/makepkg.conf" exit 1 fi if [ -z "$SVNROOT" ]; then echo "adopt: Please set the SVNROOT variable in /etc/makepkg.conf" exit 1 fi if [ -z "$1" ]; then echo "Syntax: adopt pkgname" exit 1 fi pkgname="$1" if [ ! -d "$SVNROOT/$pkgname" ] echo "adopt: no package $pkgname in $SVNROOT" exit 1 fi pushd "$SVNROOT/$pkgname" > /dev/null if [ ! -f PKGBUILD ]; then echo "adopt: $pkgname exists, but no PKGBUILD." fi sed -i "/^maintainer.*/d" PKGBUILD echo "maintainer=($MAINTAINER)" >> PKGBUILD svn commit -m "changed maintainer to $MAINTAINER" # probably give a check to see if uname of svn user same as $MAINTAINER echo "adopted $pkgname" popd > /dev/null # EOF A small note: I'm using makepkg.conf here but MAINTAINER and SVNROOT could be put in some other configuration file as well. Finally after setting all this up; adopting should become as easy as: $ adopt pkg pkg adopted That's it! All the manual work is hidden away in this script. Of course, all that is really needed is an easy way of getting the current maintainers. I'll work on adding some kind of API to the web interface to output the maintainer name given an URI like this: http://archlinux.org/packages/core/i686/bash/maintainer -- Abhishek
Am Sat, 23 May 2009 10:28:08 +0530 schrieb Abhishek Dasgupta <abhidg@gmail.com>:
Of course, all that is really needed is an easy way of getting the current maintainers. I'll work on adding some kind of API to the web interface to output the maintainer name given an URI like this: http://archlinux.org/packages/core/i686/bash/maintainer
This is for the repos. But what's about the AUR packages? For AUR you should also keep in mind, that some/most people are registered with their nicknames only, but - at least in my case - use their real names and a different e-mail address in their Maintainer flag. In such cases, the field for the real name would need to be filled out in the AUR account. Heiko
2009/5/23 Abhishek Dasgupta <abhidg@gmail.com>:
Of course, all that is really needed is an easy way of getting the current maintainers. I'll work on adding some kind of API to the web interface to output the maintainer name given an URI like this: http://archlinux.org/packages/core/i686/bash/maintainer
This is now in place: for example see http://www.archlinux.org/packages/extra/i686/namcap/maintainer/ I'll write a script to fetch the maintainers of all packages in the official repositories and store them in a simple text file, so that people who need the maintainer information for the whole archive can just use that instead of polling archlinux.org -- Abhishek
2009/5/30 Abhishek Dasgupta <abhidg@gmail.com>:
I'll write a script to fetch the maintainers of all packages in the official repositories and store them in a simple text file, so that people who need the maintainer information for the whole archive can just use that instead of polling archlinux.org
The list of maintainers will soon be at http://abhidg.mine.nu/arch/maintainers.txt It'll be updated daily at 0430 UTC. The script used is given below: #!/bin/sh URL="http://www.archlinux.org/packages" OUTPUT=/arch/maintainers.txt arch=i686 if [ ! -f /etc/abs.conf ]; then echo "This program needs 'abs' (pacman -S abs)." exit 1 fi if [ ! -x /usr/bin/curl ]; then echo "This program needs 'curl' (pacman -S curl)." exit 1 fi . /etc/abs.conf pushd "$ABSROOT" >/dev/null for repo in core extra; do pushd $repo >/dev/null for i in *; do maintainer="$(curl -s $URL/$repo/$arch/$i/maintainer/)" if ! (echo $maintainer | grep -q DOCTYPE); then echo "$i $maintainer" >> $OUTPUT.new fi done popd >/dev/null done if [ -f "$OUTPUT" ]; then mv "$OUTPUT" "$OUTPUT.old" fi mv "$OUTPUT.new" "$OUTPUT" -- Abhishek
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
Sorry, I was a bit behind on this thread so this reply is a little late. The web interface keeps track of the current package owner for all repos, right? Why not let the web interface handle the maintainer tag when a PKGBUILD is uploaded or when a package is adopted or disowned. It would be a simple matter of appending/replacing a field or a comment (the former if the information should be readily obtainable through pacman). This would free the actual maintainer from having to worry about it and would not change the current adoptation/orphaning process. Xyne
On Fri, 2009-05-22 at 19:35 +0530, Abhishek Dasgupta wrote:
2009/5/22 Allan McRae <allan@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.
If those fields were a bash variable...... A utility could be written to find PKGBUILDs maintained by people no longer active/verify that all PKGBUILDS in core/extra have a active maintainer.
Am Fri, 22 May 2009 17:16:31 +0530 schrieb Abhishek Dasgupta <abhidg@gmail.com>:
2009/5/22 Heiko Baums <lists@baums-on-web.de>:
Comments are more flexible, so that more maintainers and contributors can be added to the PKGBUILD.In this case the PKGBUILD can be parsed by AUR - it's already done anyway - when a package is uploaded to AUR.
No, it isn't; no script parses the Maintainer or Contributor tags since they are just comments and in quite a few cases have incorrect maintainers listed.
Well, the Maintainer and Contributor tags are not parsed yet, but the PKGBUILD is parsed, because the package name, the description, sources, etc. are read from the PKGBUILD by AUR. So this could also be done with the Maintainer and Contributor tags. Heiko
participants (13)
-
Abhishek Dasgupta
-
Allan McRae
-
Alper KANAT
-
Andrei Thorp
-
Angel Velásquez
-
Baho Utot
-
Chris Brannon
-
Daenyth Blank
-
Gerardo Exequiel Pozzi
-
Heiko Baums
-
hollunder＠gmx.at
-
Ray Rashif
-
Xyne