FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 09-20-2008, 10:24 PM
"Dusty Phillips"
 
Default Let's use the Maintainer tag

2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
> Hey devs,
>
> I think our current method of organizing maintainership of packages is not
> optimal. One problem is that we loose those meta information from time to time
> (we have 2667 orphaned packages atm). Also the webinterface for adopting
> packages is not the best solution I could think of. You have to adopt every
> single arch and if you put a package into testing you'll have to adopt it
> again.
>
> On the other side we have the Maintainer tag within our PKGBUILDs since a long
> time, but we don't make use of it. My idea would be parsing those tags
> (multipile maintainers should be possible) with makepkg and put those
> information in every package. In addition to this repo-add should store this
> data in the db-files, too.
>
> That would make things a lot easier, more robust (we have all data stored in
> svn) and consistent. This would also decrease the complexity of the
> webfrontend a lot; it allready reads data from the sync-dbs.
>
> And last but not least support could be added to pacman to display the
> mainter(s). ATM it only shows the packager which confuses some people.

I'm all for it; it would make the web interface more robust. I don't
think the issue with packages being orphaned will come up again, but
having that data accurate in each PKGBUILD and .pkg.tar.gz file would
make the entire world a much better place. (Especially greenland)

Dusty
 
Old 09-20-2008, 11:19 PM
Allan McRae
 
Default Let's use the Maintainer tag

Pierre Schmitz wrote:

Hey devs,

I think our current method of organizing maintainership of packages is not
optimal. One problem is that we loose those meta information from time to time
(we have 2667 orphaned packages atm). Also the webinterface for adopting
packages is not the best solution I could think of. You have to adopt every
single arch and if you put a package into testing you'll have to adopt it
again.


On the other side we have the Maintainer tag within our PKGBUILDs since a long
time, but we don't make use of it. My idea would be parsing those tags
(multipile maintainers should be possible) with makepkg and put those
information in every package. In addition to this repo-add should store this
data in the db-files, too.


That would make things a lot easier, more robust (we have all data stored in
svn) and consistent. This would also decrease the complexity of the
webfrontend a lot; it allready reads data from the sync-dbs.


And last but not least support could be added to pacman to display the
mainter(s). ATM it only shows the packager which confuses some people.



I like the idea but I think it would be better to just have something
parse the SVN repo. Currently makepkg does not see the Maintainer entry
as it is a comment. So to have this information get into packages, we
would need to either change how we set the maintainer field in PKGBUILDs
or some other hack. Having the maintainer based on the current field in
SVN trunk would also allow for orphaning (just remove field) and
adoption without having to rebuild the package.


Allan
 
Old 09-20-2008, 11:23 PM
"Dan McGee"
 
Default Let's use the Maintainer tag

On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
> 2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
>> Hey devs,
>>
>> I think our current method of organizing maintainership of packages is not
>> optimal. One problem is that we loose those meta information from time to time
>> (we have 2667 orphaned packages atm). Also the webinterface for adopting
>> packages is not the best solution I could think of. You have to adopt every
>> single arch and if you put a package into testing you'll have to adopt it
>> again.
>>
>> On the other side we have the Maintainer tag within our PKGBUILDs since a long
>> time, but we don't make use of it. My idea would be parsing those tags
>> (multipile maintainers should be possible) with makepkg and put those
>> information in every package. In addition to this repo-add should store this
>> data in the db-files, too.

I see a few problems/issues here.
1) Maintainer is a shell script comment. This means it is completely
ignored by makepkg, and I will NOT manually parse the file for this
one piece of information, it is just not worth it.
2) Your name will end up in packages you never built. Anyone building
a package from ABS and customizing it doesn't delete the maintainer
tag, and then people will come to you with questions about
pidgin-awesome or something and you will have no idea what they are
talking about.
3) All of this pertains only to organizational issues. Personal users
of makepkg have no real use for this.

>> That would make things a lot easier, more robust (we have all data stored in
>> svn) and consistent. This would also decrease the complexity of the
>> webfrontend a lot; it allready reads data from the sync-dbs.
>>
>> And last but not least support could be added to pacman to display the
>> mainter(s). ATM it only shows the packager which confuses some people.
>
> I'm all for it; it would make the web interface more robust. I don't
> think the issue with packages being orphaned will come up again, but
> having that data accurate in each PKGBUILD and .pkg.tar.gz file would
> make the entire world a much better place. (Especially greenland)

I see the problem we are trying to solve, but I'm not convinced this
is the best way to do it. I wish I had an idea to propose though...

-Dan
 
Old 09-21-2008, 03:50 AM
"Dusty Phillips"
 
Default Let's use the Maintainer tag

For the record, there is already maintainer information stored in the
.db.tar.gz -- I don't know where it comes from but I noticed it there
when I was debugging the last issue.

Another option is automatically setting the maintainer flag to whoever
updates the package. There could be an override to the command or hook
that does this so that people can update other people's packages when
necessary.

Dusty

2008/9/20 Dan McGee <dpmcgee@gmail.com>:
> On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
>> 2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
>>> Hey devs,
>>>
>>> I think our current method of organizing maintainership of packages is not
>>> optimal. One problem is that we loose those meta information from time to time
>>> (we have 2667 orphaned packages atm). Also the webinterface for adopting
>>> packages is not the best solution I could think of. You have to adopt every
>>> single arch and if you put a package into testing you'll have to adopt it
>>> again.
>>>
>>> On the other side we have the Maintainer tag within our PKGBUILDs since a long
>>> time, but we don't make use of it. My idea would be parsing those tags
>>> (multipile maintainers should be possible) with makepkg and put those
>>> information in every package. In addition to this repo-add should store this
>>> data in the db-files, too.
>
> I see a few problems/issues here.
> 1) Maintainer is a shell script comment. This means it is completely
> ignored by makepkg, and I will NOT manually parse the file for this
> one piece of information, it is just not worth it.
> 2) Your name will end up in packages you never built. Anyone building
> a package from ABS and customizing it doesn't delete the maintainer
> tag, and then people will come to you with questions about
> pidgin-awesome or something and you will have no idea what they are
> talking about.
> 3) All of this pertains only to organizational issues. Personal users
> of makepkg have no real use for this.
>
>>> That would make things a lot easier, more robust (we have all data stored in
>>> svn) and consistent. This would also decrease the complexity of the
>>> webfrontend a lot; it allready reads data from the sync-dbs.
>>>
>>> And last but not least support could be added to pacman to display the
>>> mainter(s). ATM it only shows the packager which confuses some people.
>>
>> I'm all for it; it would make the web interface more robust. I don't
>> think the issue with packages being orphaned will come up again, but
>> having that data accurate in each PKGBUILD and .pkg.tar.gz file would
>> make the entire world a much better place. (Especially greenland)
>
> I see the problem we are trying to solve, but I'm not convinced this
> is the best way to do it. I wish I had an idea to propose though...
>
> -Dan
>
 
Old 09-21-2008, 04:42 AM
Eric Belanger
 
Default Let's use the Maintainer tag

On Sat, 20 Sep 2008, Dusty Phillips wrote:


For the record, there is already maintainer information stored in the
.db.tar.gz -- I don't know where it comes from but I noticed it there
when I was debugging the last issue.


What you saw was probably the packager info which is not the same as the
maintainer.




Another option is automatically setting the maintainer flag to whoever
updates the package. There could be an override to the command or hook
that does this so that people can update other people's packages when
necessary.


That seems messy. Especially for things as x86_64 builds and testing
rebuilds.




Dusty

2008/9/20 Dan McGee <dpmcgee@gmail.com>:

On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:

2008/9/20 Pierre Schmitz <pierre@archlinux.de>:

Hey devs,

I think our current method of organizing maintainership of packages is not
optimal. One problem is that we loose those meta information from time to time
(we have 2667 orphaned packages atm). Also the webinterface for adopting
packages is not the best solution I could think of. You have to adopt every
single arch and if you put a package into testing you'll have to adopt it
again.

On the other side we have the Maintainer tag within our PKGBUILDs since a long
time, but we don't make use of it. My idea would be parsing those tags
(multipile maintainers should be possible) with makepkg and put those
information in every package. In addition to this repo-add should store this
data in the db-files, too.


I see a few problems/issues here.
1) Maintainer is a shell script comment. This means it is completely
ignored by makepkg, and I will NOT manually parse the file for this
one piece of information, it is just not worth it.
2) Your name will end up in packages you never built. Anyone building
a package from ABS and customizing it doesn't delete the maintainer
tag, and then people will come to you with questions about
pidgin-awesome or something and you will have no idea what they are
talking about.
3) All of this pertains only to organizational issues. Personal users
of makepkg have no real use for this.


That would make things a lot easier, more robust (we have all data stored in
svn) and consistent. This would also decrease the complexity of the
webfrontend a lot; it allready reads data from the sync-dbs.

And last but not least support could be added to pacman to display the
mainter(s). ATM it only shows the packager which confuses some people.


I'm all for it; it would make the web interface more robust. I don't
think the issue with packages being orphaned will come up again, but
having that data accurate in each PKGBUILD and .pkg.tar.gz file would
make the entire world a much better place. (Especially greenland)


I see the problem we are trying to solve, but I'm not convinced this
is the best way to do it. I wish I had an idea to propose though...

-Dan






--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
 
Old 09-22-2008, 03:57 AM
"Aaron Griffin"
 
Default Let's use the Maintainer tag

On Sat, Sep 20, 2008 at 6:23 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
>> 2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
>>> Hey devs,
>>>
>>> I think our current method of organizing maintainership of packages is not
>>> optimal. One problem is that we loose those meta information from time to time
>>> (we have 2667 orphaned packages atm). Also the webinterface for adopting
>>> packages is not the best solution I could think of. You have to adopt every
>>> single arch and if you put a package into testing you'll have to adopt it
>>> again.
>>>
>>> On the other side we have the Maintainer tag within our PKGBUILDs since a long
>>> time, but we don't make use of it. My idea would be parsing those tags
>>> (multipile maintainers should be possible) with makepkg and put those
>>> information in every package. In addition to this repo-add should store this
>>> data in the db-files, too.
>
> I see a few problems/issues here.
> 1) Maintainer is a shell script comment. This means it is completely
> ignored by makepkg, and I will NOT manually parse the file for this
> one piece of information, it is just not worth it.
> 2) Your name will end up in packages you never built. Anyone building
> a package from ABS and customizing it doesn't delete the maintainer
> tag, and then people will come to you with questions about
> pidgin-awesome or something and you will have no idea what they are
> talking about.
> 3) All of this pertains only to organizational issues. Personal users
> of makepkg have no real use for this.

As Eric pointed out, Pierre is talking about the maintainer of the
PKGBUILD, not the builder of the package.

Additionally, if parsing shell scripts is the issue here, why not add
some new metainfo:
maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"

Seems ok to me. We could even start doing it right now, as makepkg
will just ignore it for now
 
Old 09-22-2008, 03:58 AM
"Aaron Griffin"
 
Default Let's use the Maintainer tag

On Sun, Sep 21, 2008 at 10:57 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> Additionally, if parsing shell scripts is the issue here, why not add
> some new metainfo:
> maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"
>
> Seems ok to me. We could even start doing it right now, as makepkg
> will just ignore it for now

Side note. Just to future-proof this, we'd probably want an array, for
the case of multiple maintainers
 
Old 09-22-2008, 01:34 PM
Paul Mattal
 
Default Let's use the Maintainer tag

Aaron Griffin wrote:

On Sun, Sep 21, 2008 at 10:57 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:

Additionally, if parsing shell scripts is the issue here, why not add
some new metainfo:
maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"

Seems ok to me. We could even start doing it right now, as makepkg
will just ignore it for now


Side note. Just to future-proof this, we'd probably want an array, for
the case of multiple maintainers


+2

- P
 
Old 09-22-2008, 03:12 PM
"Phil Dillon-Thiselton"
 
Default Let's use the Maintainer tag

2008/9/22 Aaron Griffin <aaronmgriffin@gmail.com>:
>
> As Eric pointed out, Pierre is talking about the maintainer of the
> PKGBUILD, not the builder of the package.
>
> Additionally, if parsing shell scripts is the issue here, why not add
> some new metainfo:
> maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"

I think a new metainfo is a nice idea but it'd be cool if the devs
could additionally be allocated a unique ID that can be cross-reffed
to a dbase to avoid having to update the email manually/avoid having
an out of date email in an old file.

The first thing that springs to mind as an ID is the list of names on
http://www.archlinux.org/developers/ e.g.

maintainer=(AaronG DanM)

I'm thinking these could be nicely parsed out in/by the web interface
and linked up to hopefully up to date contact details.

A few caveats instantly spring to mind, such as this is only really
implementable for official pkgs and devs, but it can also provide nice
meta info for AUR pkgs.

>
> Seems ok to me. We could even start doing it right now, as makepkg
> will just ignore it for now
>
 
Old 09-22-2008, 06:46 PM
Pierre Schmitz
 
Default Let's use the Maintainer tag

Am Montag 22 September 2008 17:12:08 schrieb Phil Dillon-Thiselton:
> I think a new metainfo is a nice idea but it'd be cool if the devs
> could additionally be allocated a unique ID that can be cross-reffed
> to a dbase to avoid having to update the email manually/avoid having
> an out of date email in an old file.

We all have an adress like <username>@archlinux.org. So I would prefere this
solution. That would also be consistent to the packager data.

--

Pierre Schmitz


Clemens-August-Straße 76
53115 Bonn

Telefon 0228 9716608
Mobil 0160 95269831
Jabber pierre@jabber.archlinux.de
WWW http://www.archlinux.de
 

Thread Tools




All times are GMT. The time now is 02:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org