Quantcast

Proposals For PKGBUILD Issues

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposals For PKGBUILD Issues

Callan Barrett
At the moment there is no clear guide on a couple of recurring issues
in AUR and [community] packages, I have some proposals for new
guidelines which I think we should approve, they have no downside and
are simply to clarify what is already being done. These would, of
course, not be applied in the official Arch repositories as I have no
jurisdiction of them and they have special cases as opposed to
[community] and the AUR.

The first problem is that of "base" dependencies in PKGBUILDs.
Currently there is no rule I know of that states whether or not a
dependency from the base group of packages in the [current] repository
should be included in the depends/makedepends array of a PKGBUILD.
As an example, if we install a package which depends on gcc,
coreutils, the autotools and any other base packages should they be
included or not in the arrays?

For this problem I propose that if a package depends on another
package in the "base" group of [current] it is not required in the
depends or makedepends array of said package. For consistency's sake
this should also be the case for bash/perl/etc. scripts, although this
is probably up for debate. If this guideline is taken on board it
would greatly reduce any confusion and needless complication in a
PKGBUILD.

The second issue is the case of development versions of packages being
added to the [community] repository (svn, cvs, hg, git, etc. package
versions). This is a complete gray area for everyone, I've not seen a
single document or post stating whether or not they're allowed in
[community]. The fact is there is simply a conflict of interest
between many of the TUs on whether they're allowed in or not, nothing
official (prove me wrong).

I propose that these devel packages should be allowed into [community]
without question provided the maintainer is willing to actually
maintain it and not just let it rot after a week. I don't see a single
practical reason for not letting these packages into the repository,
while they are *potentially* unstable it would always be the choice of
the user whether or not they should be installed.

As these would be guidelines they shouldn't be treated as strict law,
but simply as clarification for both of these issues, nothing too
outrageous could slip by if it still stuck with the guidelines that
way. If you're going to debate any of these please provide good points
so they can be changed to something we all agree on. I think
eventually at least some form of the above two proposals need to be
accepted to stop a lot of confusion, it's a mess at the moment.

Also, do we even have a document for cases like these? A wiki page or
something? If we don't I imagine that's the reason these are even
issues to begin with.

Thanks.
--
Callan 'wizzomafizzo' Barrett

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Aaron Bull Schaefer
On 7/20/07, Callan Barrett <[hidden email]> wrote:

> At the moment there is no clear guide on a couple of recurring issues
> in AUR and [community] packages, I have some proposals for new
> guidelines which I think we should approve, they have no downside and
> are simply to clarify what is already being done. These would, of
> course, not be applied in the official Arch repositories as I have no
> jurisdiction of them and they have special cases as opposed to
> [community] and the AUR.
>
> The first problem is that of "base" dependencies in PKGBUILDs.
> Currently there is no rule I know of that states whether or not a
> dependency from the base group of packages in the [current] repository
> should be included in the depends/makedepends array of a PKGBUILD.
> As an example, if we install a package which depends on gcc,
> coreutils, the autotools and any other base packages should they be
> included or not in the arrays?
>
> For this problem I propose that if a package depends on another
> package in the "base" group of [current] it is not required in the
> depends or makedepends array of said package. For consistency's sake
> this should also be the case for bash/perl/etc. scripts, although this
> is probably up for debate. If this guideline is taken on board it
> would greatly reduce any confusion and needless complication in a
> PKGBUILD.
>
> The second issue is the case of development versions of packages being
> added to the [community] repository (svn, cvs, hg, git, etc. package
> versions). This is a complete gray area for everyone, I've not seen a
> single document or post stating whether or not they're allowed in
> [community]. The fact is there is simply a conflict of interest
> between many of the TUs on whether they're allowed in or not, nothing
> official (prove me wrong).
>
> I propose that these devel packages should be allowed into [community]
> without question provided the maintainer is willing to actually
> maintain it and not just let it rot after a week. I don't see a single
> practical reason for not letting these packages into the repository,
> while they are *potentially* unstable it would always be the choice of
> the user whether or not they should be installed.
>
> As these would be guidelines they shouldn't be treated as strict law,
> but simply as clarification for both of these issues, nothing too
> outrageous could slip by if it still stuck with the guidelines that
> way. If you're going to debate any of these please provide good points
> so they can be changed to something we all agree on. I think
> eventually at least some form of the above two proposals need to be
> accepted to stop a lot of confusion, it's a mess at the moment.
>
> Also, do we even have a document for cases like these? A wiki page or
> something? If we don't I imagine that's the reason these are even
> issues to begin with.
>
> Thanks.
> --
> Callan 'wizzomafizzo' Barrett

For the first issue, I would disagree and argue that it would be a
good idea to have base packages listed as dependencies because you
can't guarantee what people have installed on their systems.  Most of
the time you can guess that they'll have all of base installed, but I
know I selectively remove things from base when I do installations,
and some people strive to have an absolute minimum number of packages
installed for their purposes (i.e. for a router installation, etc.)
and they could still want to install stuff from community.  Including
them adds some form of documentation as well as ensures that things
won't get borked for those people who might not have all of base
installed.

For the second issue, I too see no issue with allowing development
packages (svn, git, etc.) to be included in community.  Once more
details get hashed out, the wiki would be the natural place to
document the consensus, such as on the ABS page or on the specific svn
package guidelines page.

--
Aaron "ElasticDog" Schaefer

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Alessio Bolognino
On Fri 2007-07-20 18:57 , Aaron Schaefer wrote:

> On 7/20/07, Callan Barrett <[hidden email]> wrote:
> > At the moment there is no clear guide on a couple of recurring issues
> > in AUR and [community] packages, I have some proposals for new
> > guidelines which I think we should approve, they have no downside and
> > are simply to clarify what is already being done. These would, of
> > course, not be applied in the official Arch repositories as I have no
> > jurisdiction of them and they have special cases as opposed to
> > [community] and the AUR.
> >
> > The first problem is that of "base" dependencies in PKGBUILDs.
> > Currently there is no rule I know of that states whether or not a
> > dependency from the base group of packages in the [current] repository
> > should be included in the depends/makedepends array of a PKGBUILD.
> > As an example, if we install a package which depends on gcc,
> > coreutils, the autotools and any other base packages should they be
> > included or not in the arrays?
> >
> > For this problem I propose that if a package depends on another
> > package in the "base" group of [current] it is not required in the
> > depends or makedepends array of said package. For consistency's sake
> > this should also be the case for bash/perl/etc. scripts, although this
> > is probably up for debate. If this guideline is taken on board it
> > would greatly reduce any confusion and needless complication in a
> > PKGBUILD.
> >
> > The second issue is the case of development versions of packages being
> > added to the [community] repository (svn, cvs, hg, git, etc. package
> > versions). This is a complete gray area for everyone, I've not seen a
> > single document or post stating whether or not they're allowed in
> > [community]. The fact is there is simply a conflict of interest
> > between many of the TUs on whether they're allowed in or not, nothing
> > official (prove me wrong).
> >
> > I propose that these devel packages should be allowed into [community]
> > without question provided the maintainer is willing to actually
> > maintain it and not just let it rot after a week. I don't see a single
> > practical reason for not letting these packages into the repository,
> > while they are *potentially* unstable it would always be the choice of
> > the user whether or not they should be installed.
> >
> > As these would be guidelines they shouldn't be treated as strict law,
> > but simply as clarification for both of these issues, nothing too
> > outrageous could slip by if it still stuck with the guidelines that
> > way. If you're going to debate any of these please provide good points
> > so they can be changed to something we all agree on. I think
> > eventually at least some form of the above two proposals need to be
> > accepted to stop a lot of confusion, it's a mess at the moment.
> >
> > Also, do we even have a document for cases like these? A wiki page or
> > something? If we don't I imagine that's the reason these are even
> > issues to begin with.
> >
> > Thanks.
> > --
> > Callan 'wizzomafizzo' Barrett
>
> For the first issue, I would disagree and argue that it would be a
> good idea to have base packages listed as dependencies because you
> can't guarantee what people have installed on their systems.  Most of
> the time you can guess that they'll have all of base installed, but I
> know I selectively remove things from base when I do installations,
> and some people strive to have an absolute minimum number of packages
> installed for their purposes (i.e. for a router installation, etc.)
> and they could still want to install stuff from community.  Including
> them adds some form of documentation as well as ensures that things
> won't get borked for those people who might not have all of base
> installed.
I agree with Aaron here. Base packages could even change and it would be
an annoyance to add/remove dependencies every time a package is
removed/added to base packages set.

> For the second issue, I too see no issue with allowing development
> packages (svn, git, etc.) to be included in community.  Once more
> details get hashed out, the wiki would be the natural place to
> document the consensus, such as on the ABS page or on the specific svn
> package guidelines page.

I think that if a TU really wants to maintain a package, he should can
do it (Development packages usually don't conflict with other packages);
[unstable] or [community], IMHO are only labels, I don't care if a
packages is maintained by a dev or a TU.
Anyway development packages are already in [community]:
 
  pacman -Sl community | egrep '\-(svn|cvs|git|devel)' | wc -l
  65

:)
My two cents,

--
Alessio 'mOLOk' Bolognino
Arch Linux Trusted User

Please send personal email to [hidden email]

Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB
GPG Key ID = 1024D / FE0270FB 2007-04-11
Key Fingerprint = 9AF8 9011 F271 450D 59CF  2D7D 96C9 8F2A FE02 70FB

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Callan Barrett
On 7/21/07, Alessio 'mOLOk' Bolognino <[hidden email]> wrote:

> On Fri 2007-07-20 18:57 , Aaron Schaefer wrote:
> > For the first issue, I would disagree and argue that it would be a
> > good idea to have base packages listed as dependencies because you
> > can't guarantee what people have installed on their systems.  Most of
> > the time you can guess that they'll have all of base installed, but I
> > know I selectively remove things from base when I do installations,
> > and some people strive to have an absolute minimum number of packages
> > installed for their purposes (i.e. for a router installation, etc.)
> > and they could still want to install stuff from community.  Including
>
> I agree with Aaron here. Base packages could even change and it would be
> an annoyance to add/remove dependencies every time a package is
> removed/added to base packages set.

I'm going to go out on a total limb here and guess *most* of our users
don't spend their time building Arch-based specialist router
distributions (of course there are going to be exceptions, you can't
cater for everyone) and I really think that's a poor argument against
base packages not being in depends. I don't know where else to go with
this other than a vote, which I think would go completely unnoticed.
Maybe this is an issue better suited for devland to figure out... I
don't know.

> > For the second issue, I too see no issue with allowing development
> > packages (svn, git, etc.) to be included in community.  Once more
> > details get hashed out, the wiki would be the natural place to
> > document the consensus, such as on the ABS page or on the specific svn
> > package guidelines page.
>
> I think that if a TU really wants to maintain a package, he should can
> do it (Development packages usually don't conflict with other packages);
> [unstable] or [community], IMHO are only labels, I don't care if a
> packages is maintained by a dev or a TU.

Sounds good, still wouldn't mind hearing anyone else's opinion but
hopefully we could make this official at some point.

--
Callan 'wizzomafizzo' Barrett

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

tardo

>>> For the second issue, I too see no issue with allowing development
>>> packages (svn, git, etc.) to be included in community.  Once more
>>> details get hashed out, the wiki would be the natural place to
>>> document the consensus, such as on the ABS page or on the specific svn
>>> package guidelines page.
>>>      
>> I think that if a TU really wants to maintain a package, he should can
>> do it (Development packages usually don't conflict with other packages);
>> [unstable] or [community], IMHO are only labels, I don't care if a
>> packages is maintained by a dev or a TU.
>>    
>
> Sounds good, still wouldn't mind hearing anyone else's opinion but
> hopefully we could make this official at some point.
>
>  
I'm still a bit undecided on this. I too think that if someone wants to
maintain them in community they should feel free to do so, but the
problem I have with this is that almost *no-one* will maintain the
x86_64 side of it. It's hard enough maintaining community64 as it is
right now, adding more -svn/cvs/etc packages just increases the workload
in my opinion.

Either way, if it comes down to it, I'd probably vote yes for this one.
No opinion on the first issue though.

- tardo

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Paul Mattal
In reply to this post by Callan Barrett
Callan Barrett wrote:

> At the moment there is no clear guide on a couple of recurring issues
> in AUR and [community] packages, I have some proposals for new
> guidelines which I think we should approve, they have no downside and
> are simply to clarify what is already being done. These would, of
> course, not be applied in the official Arch repositories as I have no
> jurisdiction of them and they have special cases as opposed to
> [community] and the AUR.
>
> The first problem is that of "base" dependencies in PKGBUILDs.
> Currently there is no rule I know of that states whether or not a
> dependency from the base group of packages in the [current] repository
> should be included in the depends/makedepends array of a PKGBUILD.
> As an example, if we install a package which depends on gcc,
> coreutils, the autotools and any other base packages should they be
> included or not in the arrays?

I think they should be included. Removing base packages should not
break your system without pacman telling you what it's breaking.
This is the point of having a package manager that understands
dependencies in the first place.

Also, what's in base has changed over time. You can't necessarily
assume what is in the current base installer is installed on
someone's machine.

> The second issue is the case of development versions of packages being
> added to the [community] repository (svn, cvs, hg, git, etc. package
> versions). This is a complete gray area for everyone, I've not seen a
> single document or post stating whether or not they're allowed in
> [community]. The fact is there is simply a conflict of interest
> between many of the TUs on whether they're allowed in or not, nothing
> official (prove me wrong).
>
> I propose that these devel packages should be allowed into [community]
> without question provided the maintainer is willing to actually
> maintain it and not just let it rot after a week. I don't see a single
> practical reason for not letting these packages into the repository,
> while they are *potentially* unstable it would always be the choice of
> the user whether or not they should be installed.

Agreed. Some software, for instance ffmpeg, hasn't released in
years, instead encouraging people to use snapshots. Other
development is heavily release-oriented. We have to remain flexible.

- P

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Phil Dillon-Thiselton
In reply to this post by Callan Barrett
On 20/07/07, Callan Barrett <[hidden email]> wrote:
> The first problem is that of "base" dependencies in PKGBUILDs.
> Currently there is no rule I know of that states whether or not a
> dependency from the base group of packages in the [current] repository
> should be included in the depends/makedepends array of a PKGBUILD.
> As an example, if we install a package which depends on gcc,
> coreutils, the autotools and any other base packages should they be
> included or not in the arrays?

This looks like one of those Arch Linux myths: that you shouldn't
include certain pkgs in the depends array because you can assume
people have them?  Put like that I think it's pretty clear that you
can't make such an assumption and so you do need to include them,
unless of course they are already a dep of another dep:

foobar depends on block and tackle, but block depends on tackle, so
foobar only needs to depend on block.

> The second issue is the case of development versions of packages being
> added to the [community] repository (svn, cvs, hg, git, etc. package
> versions). This is a complete gray area for everyone, I've not seen a
> single document or post stating whether or not they're allowed in
> [community]. The fact is there is simply a conflict of interest
> between many of the TUs on whether they're allowed in or not, nothing
> official (prove me wrong).

I think Arch probably needs to "get with the programme" when it comes
to SCM snapshot builds.  If people want to make them then we should be
supporting them if we can.  I originally created versionpkg to
facilitate the process of updating them and I am considering a
proposal that will incorporate certain aspects of SCM builds directly
into makepkg.

Now, initially this might not prove popular amongst the other devs,
but I think with the right planning, rationale and implementation it
will be nothing but good sense.

When you consider that Arch now directly provides various -git and
-svn version within it's official repos official support for building
such pkgs seems far from unreasonable.

I hope that should help to settle this matter once and for all.

Best,

Phil

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Callan Barrett
On 7/23/07, Phil Dillon-Thiselton <[hidden email]> wrote:
> This looks like one of those Arch Linux myths: that you shouldn't
> include certain pkgs in the depends array because you can assume
> people have them?  Put like that I think it's pretty clear that you
> can't make such an assumption and so you do need to include them,
> unless of course they are already a dep of another dep:
>
> foobar depends on block and tackle, but block depends on tackle, so
> foobar only needs to depend on block.

Before I wrote that up I was told by several people base in depends is
a bad idea, all the replies I've gotten on the ML completely differ to
those from IRC. I feel like I can safely assume there's a pretty much
50/50 split on people who want base in depends and people who don't.

I think after talking some more with people this is better left up to
common sense, as with most aspects of writing PKGBUILDs. We should
probably drop this one altogether, I see it getting nowhere and is not
worth the trouble.

As for the devel packages in [community], great. It feels good to
finally get this figured out. So can we all agree that as long as the
maintainer is willing to do their job and maintain there is no problem
whatsoever with them being in [community]?

I don't think a vote is required because as pointed out [community] is
already ripe with the devel packages, but as long as we can agree on
this there won't be anymore discouraging of people uploading packages
in the first place.

--
Callan 'wizzomafizzo' Barrett

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Phil Dillon-Thiselton
On 23/07/07, Callan Barrett <[hidden email]> wrote:
> Before I wrote that up I was told by several people base in depends is
> a bad idea, all the replies I've gotten on the ML completely differ to
> those from IRC. I feel like I can safely assume there's a pretty much
> 50/50 split on people who want base in depends and people who don't.

I think I must have missed the point because I can't see where the
discussion on this matter is.  The depends array should list the pkgs
that the pkg depends on, why does it matter if they do or don't
provide part of base?

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Simo Leone
On Mon, Jul 23, 2007 at 04:19:38PM +0100, Phil Dillon-Thiselton wrote:

> On 23/07/07, Callan Barrett <[hidden email]> wrote:
> > Before I wrote that up I was told by several people base in depends is
> > a bad idea, all the replies I've gotten on the ML completely differ to
> > those from IRC. I feel like I can safely assume there's a pretty much
> > 50/50 split on people who want base in depends and people who don't.
>
> I think I must have missed the point because I can't see where the
> discussion on this matter is.  The depends array should list the pkgs
> that the pkg depends on, why does it matter if they do or don't
> provide part of base?
>
Actually, it's always been pretty much accepted that base packages do
not need to be listed in the depends array. It can be assumed that base
packages will be installed on every system, or if they are not,
whoever's running the system must know what they are doing. Base
packages often get included in the depends array either simply because
someone felt like it, or because namcap picked it up and someone was too
lazy to check to see if it was in base.

So to definitively end the arument, base dependencies are optional.
Because they've always been, and there's no reason to change that.

--
Simo Leone
Arch Linux Developer

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Phil Dillon-Thiselton
On 23/07/07, Simo Leone <[hidden email]> wrote:

> On Mon, Jul 23, 2007 at 04:19:38PM +0100, Phil Dillon-Thiselton wrote:
> > I think I must have missed the point because I can't see where the
> > discussion on this matter is.  The depends array should list the pkgs
> > that the pkg depends on, why does it matter if they do or don't
> > provide part of base?
>
> Actually, it's always been pretty much accepted that base packages do
> not need to be listed in the depends array. It can be assumed that base
> packages will be installed on every system, or if they are not,
> whoever's running the system must know what they are doing. Base
> packages often get included in the depends array either simply because
> someone felt like it, or because namcap picked it up and someone was too
> lazy to check to see if it was in base.

Ah, well, there's little wonder there is so much confusion then.

> So to definitively end the arument, base dependencies are optional.
> Because they've always been, and there's no reason to change that.

Thanks for settling that, Simo.

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Scott Horowitz
In reply to this post by Simo Leone
On 7/23/07, Simo Leone <[hidden email]> wrote:
> So to definitively end the arument, base dependencies are optional.
> Because they've always been, and there's no reason to change that.

I think Alessio (and others) have brought up a very good reason for
changing this convention: the fact that base packages can potentially
change over time. It seems like a good idea to err on the side of
conservatism in this case, in order to prevent possible future
breakage.

Personally, I think the burden of evidence lays on the people who
don't want base dependencies included. I certainly haven't seen a
single good reason for not including them.

Scott

P.S. s/arument/argument/

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Jeff Mickey
On 7/23/07, Scott Horowitz <[hidden email]> wrote:
> Personally, I think the burden of evidence lays on the people who
> don't want base dependencies included. I certainly haven't seen a
> single good reason for not including them.

I agree.  I think you should include in the dependency array what the
package depends on!  If the application _only_ needs glibc, add it to
the depends array.  If it needs something else that depends on glibc,
then you shouldn't need to add glibc to the depends array.  I think
you should always be able to determine every package that is needed
for a package from it's depends array, and looking up the dependency
tree with the pacman db.

This will also help if/when the repo reorganization changes what all
is in base.  "Explicit over implicit" comes to mind once again.

    //  codemac

--
. : [ + carpe diem totus tuus + ] : .

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Eric Bélanger-2
In reply to this post by Simo Leone
On Mon, 23 Jul 2007, Simo Leone wrote:

> On Mon, Jul 23, 2007 at 04:19:38PM +0100, Phil Dillon-Thiselton wrote:
>> On 23/07/07, Callan Barrett <[hidden email]> wrote:
>>> Before I wrote that up I was told by several people base in depends is
>>> a bad idea, all the replies I've gotten on the ML completely differ to
>>> those from IRC. I feel like I can safely assume there's a pretty much
>>> 50/50 split on people who want base in depends and people who don't.
>>
>> I think I must have missed the point because I can't see where the
>> discussion on this matter is.  The depends array should list the pkgs
>> that the pkg depends on, why does it matter if they do or don't
>> provide part of base?
>>
>
> Actually, it's always been pretty much accepted that base packages do
> not need to be listed in the depends array. It can be assumed that base
> packages will be installed on every system, or if they are not,
> whoever's running the system must know what they are doing. Base
> packages often get included in the depends array either simply because
> someone felt like it, or because namcap picked it up and someone was too
> lazy to check to see if it was in base.
>
> So to definitively end the arument, base dependencies are optional.
> Because they've always been, and there's no reason to change that.
>
>

I agree.

The way I work with base dependencies is that I only include them if the
package depends on other packages in base, like a system tool that depends
only on glibc. In this case, I will include the glibc dependency because
it keeps namcap happy and I don't end up with an empty depends array. Each
time I come across a PKGBUILD in unsupported with no depends, I always
wonder if it's because it only depends on base packages or if the packager
forgot/didn't bother to find out the dependencies.  I also try to keep
the depends list as small as possible.  For example, bash
script will have a bash dependency but won't have coreutils as dependency
even if it uses these commands.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Eric Bélanger-2
In reply to this post by Paul Mattal
>>
>> I propose that these devel packages should be allowed into [community]
>> without question provided the maintainer is willing to actually
>> maintain it and not just let it rot after a week. I don't see a single
>> practical reason for not letting these packages into the repository,
>> while they are *potentially* unstable it would always be the choice of
>> the user whether or not they should be installed.
>
> Agreed. Some software, for instance ffmpeg, hasn't released in
> years, instead encouraging people to use snapshots. Other
> development is heavily release-oriented. We have to remain flexible.
>
> - P
>

My only problem with devel packages in [community] is that the community
repo was created to provide packages that were not in the official repos.
In my mind a packages and it's devel counterpart is pretty much the same
package.  I wouldn't want the community repo to become another unstable
repo maintained by TU. I have no problem with packages that didn't had a
stable release yet or for packages like ffmpeg. For the rest, we should
try to limit ourselves to the most popular devel packages or, at least, to
make sure that the number of devel packages remain a minority.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Eric Bélanger-2
In reply to this post by tardo
On Sun, 22 Jul 2007, tardo wrote:

>
>>>> For the second issue, I too see no issue with allowing development
>>>> packages (svn, git, etc.) to be included in community.  Once more
>>>> details get hashed out, the wiki would be the natural place to
>>>> document the consensus, such as on the ABS page or on the specific svn
>>>> package guidelines page.
>>>>
>>> I think that if a TU really wants to maintain a package, he should can
>>> do it (Development packages usually don't conflict with other packages);
>>> [unstable] or [community], IMHO are only labels, I don't care if a
>>> packages is maintained by a dev or a TU.
>>>
>>
>> Sounds good, still wouldn't mind hearing anyone else's opinion but
>> hopefully we could make this official at some point.
>>
>>
> I'm still a bit undecided on this. I too think that if someone wants to
> maintain them in community they should feel free to do so, but the
> problem I have with this is that almost *no-one* will maintain the
> x86_64 side of it. It's hard enough maintaining community64 as it is
> right now, adding more -svn/cvs/etc packages just increases the workload
> in my opinion.
>
> Either way, if it comes down to it, I'd probably vote yes for this one.
> No opinion on the first issue though.
>
> - tardo

There is no rule that forces the community64 repo to be in sync with the
i686 community repo or to provide the same packages. We can decide to not
include these devel packages if no x86_64 TU are interested in maintaining
them. The users can always get the PKGBUILD from cvs. They understand (and
already know) that community64 is low on man-power. I'm not sure if it's a
good idea but we can also have (some of) these devel packages but update
them at a lower frequency (e.g. every two weeks instead of weekly
updates).



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Alessio Bolognino
In reply to this post by Jeff Mickey
On Mon 2007-07-23 14:41 , Jeff Mickey wrote:

> On 7/23/07, Scott Horowitz <[hidden email]> wrote:
> > Personally, I think the burden of evidence lays on the people who
> > don't want base dependencies included. I certainly haven't seen a
> > single good reason for not including them.
>
> I agree.  I think you should include in the dependency array what the
> package depends on!  If the application _only_ needs glibc, add it to
> the depends array.  If it needs something else that depends on glibc,
> then you shouldn't need to add glibc to the depends array.  I think
> you should always be able to determine every package that is needed
> for a package from it's depends array, and looking up the dependency
> tree with the pacman db.
>
> This will also help if/when the repo reorganization changes what all
> is in base.  "Explicit over implicit" comes to mind once again.
I just thought that pacman itself is needed to install a package :)
Pacman depends (directly or indirectly) on:

acl, attr, bash, binutils, bzip2, coreutils, cracklib, db, fakeroot,
filesystem, gcc glibc, grep, kernel-headers, libarchive, libdownload, ncurses,
pam, pcre, readline shadow, zlib.

IMHO doesn't make sense to add 'zlib' as a dependency for every package, or gcc
as a makedependency, but if I'm packaging a bash script I usually add 'bash' as
a dep.
Just use common sense.

--
Alessio 'mOLOk' Bolognino
Arch Linux Trusted User

Please send personal email to [hidden email]

Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB
GPG Key ID = 1024D / FE0270FB 2007-04-11
Key Fingerprint = 9AF8 9011 F271 450D 59CF  2D7D 96C9 8F2A FE02 70FB

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users

attachment0 (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Aaron Griffin
On 7/23/07, Alessio 'mOLOk' Bolognino <[hidden email]> wrote:
> Pacman depends (directly or indirectly) on:
>
> acl, attr, bash, binutils, bzip2, coreutils, cracklib, db, fakeroot,
> filesystem, gcc glibc, grep, kernel-headers, libarchive, libdownload, ncurses,
> pam, pcre, readline shadow, zlib.

For completeness: sed and mktemp

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Paul Mattal
In reply to this post by Jeff Mickey
Jeff Mickey wrote:

> On 7/23/07, Scott Horowitz <[hidden email]> wrote:
>> Personally, I think the burden of evidence lays on the people who
>> don't want base dependencies included. I certainly haven't seen a
>> single good reason for not including them.
>
> I agree.  I think you should include in the dependency array what the
> package depends on!  If the application _only_ needs glibc, add it to
> the depends array.  If it needs something else that depends on glibc,
> then you shouldn't need to add glibc to the depends array.  I think
> you should always be able to determine every package that is needed
> for a package from it's depends array, and looking up the dependency
> tree with the pacman db.

When you hang around long enough, you realize that there's a good
counterargument to almost every aspect of dependency management.
This is why it's hard.

The dependency array tree is not necessarily reliable. Sometimes you
want to explicitly add a dependency for a library that you know is
likely to get updated out from under your package (ld.so name
changes, e.g.) like for packages like openssl or zlib or curl or ffmpeg.

This is why being a developer takes skill. There aren't easy hard
and fast rules. You have to consider the situation and make good
choices based on the facts at hand.

- P

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals For PKGBUILD Issues

Simo Leone
On Mon, Jul 23, 2007 at 04:36:43PM -0400, Paul Mattal wrote:

> Jeff Mickey wrote:
> > On 7/23/07, Scott Horowitz <[hidden email]> wrote:
> >> Personally, I think the burden of evidence lays on the people who
> >> don't want base dependencies included. I certainly haven't seen a
> >> single good reason for not including them.
> >
> > I agree.  I think you should include in the dependency array what the
> > package depends on!  If the application _only_ needs glibc, add it to
> > the depends array.  If it needs something else that depends on glibc,
> > then you shouldn't need to add glibc to the depends array.  I think
> > you should always be able to determine every package that is needed
> > for a package from it's depends array, and looking up the dependency
> > tree with the pacman db.
>
> When you hang around long enough, you realize that there's a good
> counterargument to almost every aspect of dependency management.
> This is why it's hard.
>
Such as give me a case where glibc would *not* be installed on a system?
;)

> The dependency array tree is not necessarily reliable. Sometimes you
> want to explicitly add a dependency for a library that you know is
> likely to get updated out from under your package (ld.so name
> changes, e.g.) like for packages like openssl or zlib or curl or ffmpeg.
>
> This is why being a developer takes skill. There aren't easy hard
> and fast rules. You have to consider the situation and make good
> choices based on the facts at hand.
>

Damn well put. paul++

--
Simo Leone
Arch Linux Developer

_______________________________________________
tur-users mailing list
[hidden email]
http://archlinux.org/mailman/listinfo/tur-users

attachment0 (196 bytes) Download Attachment
12
Loading...