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 User Repository

 
 
LinkBack Thread Tools
 
Old 05-26-2012, 10:58 AM
Muflone
 
Default Building a git version of a package already present in the official repositories

Hello

In the AUR section of the Arch Packaging Standards guide [1] we can read
that a package must not build any of applications in the official
repositories.


At the moment the extra/strace 4.7-1 package uses the most updated
released version of the application but the current version has a defect
with custom kernel version numbers (eg. the 3.3-pf) which renders the
tool unusable at all.
Such bug has been fixed in the git repository [2] but the author has not
yet released an updated version.


Would be allowed to build a strace-git package to always pick the most
recent version from the git repo, even if it builds a binary application
present in the official repos?

What guidelines should be followed to avoid conflicting packages?

Thanks in advance

[1]
https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_packages_to_th e_AUR
[2]
http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=0dbc80de895c25769791b7726022 a274695eec31;hp=55980f5b72000406e3fd843b098b5c1328 a21e45


--
Muflone
 
Old 05-26-2012, 11:09 AM
Sven-Hendrik Haase
 
Default Building a git version of a package already present in the official repositories

On 05/26/2012 12:58 PM, Muflone wrote:
> Hello
>
> In the AUR section of the Arch Packaging Standards guide [1] we can
> read that a package must not build any of applications in the official
> repositories.
>
> At the moment the extra/strace 4.7-1 package uses the most updated
> released version of the application but the current version has a
> defect with custom kernel version numbers (eg. the 3.3-pf) which
> renders the tool unusable at all.
> Such bug has been fixed in the git repository [2] but the author has
> not yet released an updated version.
>
> Would be allowed to build a strace-git package to always pick the most
> recent version from the git repo, even if it builds a binary
> application present in the official repos?
> What guidelines should be followed to avoid conflicting packages?
>
> Thanks in advance
>
> [1]
> https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_packages_to_th e_AUR
> [2]
> http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=0dbc80de895c25769791b7726022 a274695eec31;hp=55980f5b72000406e3fd843b098b5c1328 a21e45
>
What is the problem? You may submit a strace-git package to the AUR as
it is not merely an updated fixed version of the official package.
However, you are strongly discouraged to post a package like strace-new
that you made because of a new upstream release if the Arch package lags
a few days behind.

The best solution, though, would be to bug the strace author to make a
new release in order to fix this problem for everyone. This way, you'd
likely have a usable strace in Arch within a day.
 
Old 05-26-2012, 11:44 AM
Muflone
 
Default Building a git version of a package already present in the official repositories

Il 05/26/2012 01:09 PM, Sven-Hendrik Haase wrote:

On 05/26/2012 12:58 PM, Muflone wrote:

Hello

In the AUR section of the Arch Packaging Standards guide [1] we can
read that a package must not build any of applications in the official
repositories.

What is the problem? You may submit a strace-git package to the AUR as
it is not merely an updated fixed version of the official package.
However, you are strongly discouraged to post a package like strace-new
that you made because of a new upstream release if the Arch package lags
a few days behind.

The best solution, though, would be to bug the strace author to make a
new release in order to fix this problem for everyone. This way, you'd
likely have a usable strace in Arch within a day.



I suppose there should be a reason for the rule to deny the building of
a binary application in conflict with a package in the official
repository until some patch was applied in order to make a slight
different application, which is not this case.


To file a bug is the best solution of course but the previous was a
general packaging question.


--
Muflone
 

Thread Tools




All times are GMT. The time now is 01:55 PM.

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