Quantcast

unzip in makedepends?

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

unzip in makedepends?

bardo-2
Maybe this has been answered a lot of times, if this is the case
please bear with me. I stumbled upon eclipse-subeclipse in AUR, whose
maintainer put unzip in makedepends. Now, unzip is not in the base
package set, but a lot of packages have zipped sources. Is it right to
add unzip to makedepends when it's used only for source unpacking? And
shouldn't pacman depend on the main unpackers to make sure it covers
the majority of packages?

Some statistics.
 * The only package in current to makedepend on unzip is zip, which
has a .zip source.
 * A package with a zip source but no unzip makedep is pccts, which
has been in current until the last cleanup and is now in unsupported
(substituted by antlr, if I understood correctly.
 * There's 12 packages that have unzip in {make,}depends, while 22 use
it in build(). Of these 22, only three specify unzip between their
dependencies.

Is there any official guideline?


bardo

_______________________________________________
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: unzip in makedepends?

Roman Kyrylych
2007/6/2, bardo <[hidden email]>:

> Maybe this has been answered a lot of times, if this is the case
> please bear with me. I stumbled upon eclipse-subeclipse in AUR, whose
> maintainer put unzip in makedepends. Now, unzip is not in the base
> package set, but a lot of packages have zipped sources. Is it right to
> add unzip to makedepends when it's used only for source unpacking? And
> shouldn't pacman depend on the main unpackers to make sure it covers
> the majority of packages?
>
> Some statistics.
>  * The only package in current to makedepend on unzip is zip, which
> has a .zip source.
>  * A package with a zip source but no unzip makedep is pccts, which
> has been in current until the last cleanup and is now in unsupported
> (substituted by antlr, if I understood correctly.
>  * There's 12 packages that have unzip in {make,}depends, while 22 use
> it in build(). Of these 22, only three specify unzip between their
> dependencies.
>
> Is there any official guideline?
>

I think unzip in makedepends is OK.
Also, there are some packages that require rpmextract, cabextract and
unrar to extract sources. All are added as makedepends to those
packages.

--
Roman Kyrylych (Роман Кирилич)
_______________________________________________
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: unzip in makedepends?

Jason Chu
In reply to this post by bardo-2
On Sat, Jun 02, 2007 at 04:05:19PM +0200, bardo wrote:

> Maybe this has been answered a lot of times, if this is the case
> please bear with me. I stumbled upon eclipse-subeclipse in AUR, whose
> maintainer put unzip in makedepends. Now, unzip is not in the base
> package set, but a lot of packages have zipped sources. Is it right to
> add unzip to makedepends when it's used only for source unpacking? And
> shouldn't pacman depend on the main unpackers to make sure it covers
> the majority of packages?
>
> Some statistics.
>  * The only package in current to makedepend on unzip is zip, which
> has a .zip source.
>  * A package with a zip source but no unzip makedep is pccts, which
> has been in current until the last cleanup and is now in unsupported
> (substituted by antlr, if I understood correctly.
>  * There's 12 packages that have unzip in {make,}depends, while 22 use
> it in build(). Of these 22, only three specify unzip between their
> dependencies.
>
> Is there any official guideline?
We've had a guideline for this one.  If it's makepkg doing the extracting
(like the case of unzip before the build()), don't make it a makedepend.
In theory they should be covered by makepkg.  If unzip is used in the
build() function, then include it as a makedepend, because your build
actually needs it.

This addresses Roman's comment about cabextract, etc too.  They are all
executed in the build() function, so they should be included as a
makedepend.

Jason

_______________________________________________
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: unzip in makedepends?

bardo-2
On 6/2/07, Jason Chu <[hidden email]> wrote:
> We've had a guideline for this one.  If it's makepkg doing the extracting
> (like the case of unzip before the build()), don't make it a makedepend.
> In theory they should be covered by makepkg.  If unzip is used in the
> build() function, then include it as a makedepend, because your build
> actually needs it.

So, shouldn't unzip be in base?


Corrado

_______________________________________________
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: unzip in makedepends?

Jason Chu
On Sat, Jun 02, 2007 at 07:59:58PM +0200, bardo wrote:
> On 6/2/07, Jason Chu <[hidden email]> wrote:
> > We've had a guideline for this one.  If it's makepkg doing the extracting
> > (like the case of unzip before the build()), don't make it a makedepend.
> > In theory they should be covered by makepkg.  If unzip is used in the
> > build() function, then include it as a makedepend, because your build
> > actually needs it.
>
> So, shouldn't unzip be in base?

It'd probably be one of the most logical places to put it.  Though, how
often do you use unzip in the regular operation of a machine?  If base is
supposed to be the bare minimum, is unzip really all that necessary?

Jason

_______________________________________________
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: unzip in makedepends?

bardo-2
On 6/2/07, Jason Chu <[hidden email]> wrote:
> It'd probably be one of the most logical places to put it.  Though, how
> often do you use unzip in the regular operation of a machine?  If base is
> supposed to be the bare minimum, is unzip really all that necessary?

You're right, I don't use it very often, but it's still necessary for
the full operation of makepkg. How does makepkg react if unzip isn't
installed and is building a package that needs it? Just a series of
"not found" when it tries to access the various files/dirs? I have no
way to test it. And what could be a good way to handle this? A check
inside pacman that looks for the source type and warns the user?


Corrado

_______________________________________________
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: unzip in makedepends?

Jason Chu
On Sat, Jun 02, 2007 at 08:32:27PM +0200, bardo wrote:
> On 6/2/07, Jason Chu <[hidden email]> wrote:
> > It'd probably be one of the most logical places to put it.  Though, how
> > often do you use unzip in the regular operation of a machine?  If base is
> > supposed to be the bare minimum, is unzip really all that necessary?
>
> You're right, I don't use it very often, but it's still necessary for
> the full operation of makepkg. How does makepkg react if unzip isn't
> installed and is building a package that needs it? Just a series of
> "not found" when it tries to access the various files/dirs? I have no

I believe it errors out saying that it couldn't extract the source.

> way to test it. And what could be a good way to handle this? A check
> inside pacman that looks for the source type and warns the user?

A check inside makepkg with a message saying you need to install unzip
right before it tries to execute unzip would probably be good enough.

Jason

_______________________________________________
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: unzip in makedepends?

Slash-2
In reply to this post by Jason Chu
On 6/2/07, Jason Chu <[hidden email]> wrote:
> It'd probably be one of the most logical places to put it.  Though, how
> often do you use unzip in the regular operation of a machine?  If base is
> supposed to be the bare minimum, is unzip really all that necessary?
>
> Jason

I agree it's probably not appropriate in base (ie. a dependency of
pacman/makepkg). The logical consequence of that, however, is that it
must be listed as makedepend in every PKGBUILD which has zipped
sources.

I don't think it's proper to force the user to install something
manually when clearly it should be a dependency of the build tool, or
a dependency of the package the client is trying to build. Both of
these functions are supported by AL's tools, so it should be
somewhere.

The whole problem here is that the "zip" format is very popular, and a
lot of things are distributed as such, but its not popular enough for
people to consider it on the same level as gzip or bzip2. If "rar"
were more popular, I'm sure makepkg would use "unrar" and we'd be
having this same discussion.

TBH, I think the most "proper" solution to the problem is as follows:
"unzip" shouldn't be in base, and therefore "makepkg" should not
depend on it. "unzip" functionality should be removed from "makepkg"
and every PKGBUILD with "zip" sources should have "unzip" as a
makedepend and the PKGBUILD will be required to do all the
decompressing of those files- Just like they need to do for Rar, 7zip,
cabextract, rpmextract, etc. That is much cleaner, but not as
convenient, of course. "unzip" is currently in an ambiguous position.
It should be classified with base or with all the other decompression
tools. Not some hack in between.

Of course, the more "realistic" solution that I would support is to
just keep doing what we are doing; I suspect it's almost a non-issue.

-Slash

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