Pacman Suggestion

Insane-Boy · 2006-02-28 19:00:35

We all know apt-get pkg sys.. when you apt-get something ( include deps ) when the apt-get get/install deps shows .. ex:3/34 ( number / from ).Do you think that is good idea for pacman?

ozar · 2006-02-28 19:06:23

You could always turn it in as a "feature request" at the Arch bug tracker:

http://bugs.archlinux.org

I'm sure Judd will give consideration to your suggestion.

ozar

Cam · 2006-03-01 06:55:08

Seems like overkill, I remember someone saying a while ago that pacman already had too much output.

midwinter · 2006-03-01 15:01:51

Maybe that is overkill.. an overall percentage would be nice though I think, I find myself adding up the MB already downloaded all the time. But that's me.

rafal · 2006-03-01 15:40:42

I also find the feature of actual percentage of downloading to the total size of all packages would be useful as it is in apt-get.

sebcactus · 2006-03-01 16:11:05

What about tab-completion for pacman ? So that you don't have to type the whole package name.

Dusty · 2006-03-01 16:27:29

midwinter wrote:

Maybe that is overkill.. an overall percentage would be nice though I think, I find myself adding up the MB already downloaded all the time. But that's me.

I like that, it gives me something to do while I wait.

Dusty

Dusty · 2006-03-01 16:27:52

marmotte wrote:

What about tab-completion for pacman ? So that you don't have to type the whole package name.

I think the bash-completion package already has this.

Dusty

sebcactus · 2006-03-01 16:40:11

Great! I will give it a try.

whargoul · 2006-03-01 18:15:34

Pacman is good enough as it is. But there is one thing I miss. A somekind longer description of a package. Fx if type "pacman -Si package" you would get a long description of a package.

Insane-Boy · 2006-03-28 12:41:22

rafal wrote:

I also find the feature of actual percentage of downloading to the total size of all packages would be useful as it is in apt-get.

Yeah this also sounds nice.I hope to see one of these ideas in the new version of pacman.

user · 2006-03-29 18:54:01

How about pacman + paco?

pressh · 2006-03-29 19:16:09

user wrote:

How about pacman + paco?

what do you mean with this ?

if you mean a gui frontend to pacman, there are already several

user · 2006-03-29 19:19:47

pressh wrote:

if you mean a gui frontend to pacman,

Yes.

pressh · 2006-03-29 19:21:45

user wrote:

pressh wrote:
if you mean a gui frontend to pacman,
Yes.

check jacman, gtkpacman (both in community) & guzuta (AUR)

Benol · 2006-03-29 19:22:32

whargoul wrote:

Pacman is good enough as it is.

Oh, please. Pacman is OK, but it's far from beeing good enought (I don't think a programm can ever be good enought ).

First of all it lacks API for GUI front-end's (this will change soon).

Second - the srcpac functionality is a must. I don't see any other way to use ABS then with srcpac. This uh-oh ABS system wants me to go to the /var/abs/local, make a directory, copy PKGBUILD and finally compile a package that I manually have to add. I can stay with configure and make - maybe that's even faster. So Pacman3 should definitely include the srcpac "-b" option - in the end that's what the ABS is for.

There is also no promised in the docs "way to rebuild your system from source with one command" method which I know of.

Third - the extensions. *.pkg.tar.gz is faaaaaar too long and unintuitive, but OK, I can live with that (although *.pac sounds great and I can't see any rason why not to make a switch). But PKGBUILD instead of foo.pkgbuild is just stupid. If I go to AUR and download two PKGBUILDs I have to rename them or whatever, it's the worst part o pacman in my opinion.

Color output is also a very good idea, it would make pacman easier to use. Look at qpkg for example.

And the final word - if pacman was "good enought" there wouldn't be a need for scripts like srcpac, dotpac, qpkg, aurbuild and others. Pacman is just not complete.

BTW - is there a way to take part in pacman development?

elasticdog · 2006-03-29 20:10:46

Benol wrote:

Second - the srcpac functionality is a must. I don't see any other way to use ABS then with srcpac. This uh-oh ABS system wants me to go to the /var/abs/local, make a directory, copy PKGBUILD and finally compile a package that I manually have to add. I can stay with configure and make - maybe that's even faster. So Pacman3 should definitely include the srcpac "-b" option - in the end that's what the ABS is for.

It's not that difficult really, if you're installing stuff from the AUR, you just untar the file (it doesn't have to be in /var/abs/local/, but that does make a convenient place to put everything), it creates the directory for you, and then there is a flag included with <code>makepkg</code> that will install it automatically when it's done. It is way better than just compiling it yourself, since all of the files are now managed by pacman.

Benol wrote:

There is also no promised in the docs "way to rebuild your system from source with one command" method which I know of.

Try <code>makeworld</code>

Benol wrote:

Third - the extensions. *.pkg.tar.gz is faaaaaar too long and unintuitive, but OK, I can live with that (although *.pac sounds great and I can't see any rason why not to make a switch). But PKGBUILD instead of foo.pkgbuild is just stupid. If I go to AUR and download two PKGBUILDs I have to rename them or whatever, it's the worst part o pacman in my opinion.

Why is .pkg.tar.gz too long? It tells you exactly what the file is...a standard .tar.gz archive, that just so happens to contain an Arch package. As I mentioned above, if you download stuff from the AUR, just download and untar the entire archive, rather than just the PKGBUILD, especially if you're not going to customize the build.

Benol wrote:

Color output is also a very good idea, it would make pacman easier to use. Look at qpkg for example.
And the final word - if pacman was "good enought" there wouldn't be a need for scripts like srcpac, dotpac, qpkg, aurbuild and others. Pacman is just not complete.

I agree with you on color output, but a lot of these things are intentional. The AUR is part of the community and not officially supported, and thus things like aurbuild aren't part of the base pacman functionality. Also, it makes sense that the binary side of things and the source side of things are separate...source-based stuff isn't included in the official repos, so once again it falls in the domain of the ABS and the AUR. I also like the idea of dotpac, but it's not really a critical component to managing packages, it merely makes upgrading configuration files easier on the user. Really most of those projects were started because people had the desire to streamline some part of the process. Just because the tools exist, doesn't mean they should all be combined into one super tool...IMHO.

wain · 2006-03-29 21:06:41

elasticdog wrote:

Benol wrote:
There is also no promised in the docs "way to rebuild your system from source with one command" method which I know of.
Try <code>makeworld</code>

There is a lot of posts about "makeworld" or "srcpac -Syub" for rebuild the entire system... but it just don't work !

makeworld can just build all pkg from /.var/abs
srcpac -Syub can just build updated PKGBUILD

Benol · 2006-03-30 19:03:52

makeworld can just build all pkg from /.var/abs
srcpac -Syub can just build updated PKGBUILD

Exactly.

It's not that difficult really, if you're installing stuff from the AUR, you just untar the file (it doesn't have to be in /var/abs/local/, but that does make a convenient place to put everything), it creates the directory for you, and then there is a flag included with makepkg that will install it automatically when it's done. It is way better than just compiling it yourself, since all of the files are now managed by pacman.

"srcpac -Sb foo" is even less difficult I don't necessarily bind building from source with AUR. Using AUR should be somehow separeted, I'll write about that in a moment.

Why is .pkg.tar.gz too long? It tells you exactly what the file is...a standard .tar.gz archive, that just so happens to contain an Arch package. As I mentioned above, if you download stuff from the AUR, just download and untar the entire archive, rather than just the PKGBUILD, especially if you're not going to customize the build.

pkg.tar.gz tells me many things, but it doesn't tell me that this is a pacman, ArchLinux package. Using simple PKGBUILD simply has to cause overwriting something in the end. And imagine that a "third-party package" or just user contributed one (not necessarily from AUR) could be built with just "pacman -B foopackage.src.pac" - a simple extension change and look, how intuitive it gets

The AUR is part of the community and not officially supported, and thus things like aurbuild aren't part of the base pacman functionality. Also, it makes sense that the binary side of things and the source side of things are separate...source-based stuff isn't included in the official repos, so once again it falls in the domain of the ABS and the AUR.

ABS is official. AUR is official part of Arch Linux - the AUR developer is listed in "developers" on the website. Arch is binary and from-source distribution - it is often reminded, especially when comparing to Gentoo.

It could be really just that simple:

"pacman -S foo" to install binary package
"pacman -Sb foo" to build and install package (excluding AUR)
"pacman -A foo.pac" to install a local binary package
"pacman -B foo.src.pac" to build a local source package (also from AUR)
"pacman -Bi foo.src.pac" as above, with --install

This is my opinion on the subject

elasticdog · 2006-03-30 21:19:56

I don't see how labeling it <code>.pac</code> is any different than labeling it <code>.pkg</code>. Either one could be interpreted as the word package (yes, I know you'd want the .pac to represent pacman) and both extensions are in use out there (do a quick search on http://filext.com/). The only thing you're saying is that you'd want to drop the <code>.tar.gz</code> (which is the standard way to mark gunzipped tars), and add a specifier for source packages. I like knowing that the packages are just simple gunzipped tars and not some weird proprietary format of some kind...sure you can always just run <code>file example.pac</code> and it will tell you, but having the extension there removes all doubt as of to how things work.

I hadn't really looked in depth at <code>makeworld</code> and agree it would be nice to have finer-grained control than just the broad package categories. One option might be to compile everything, put it in your own repo and then update the currently installed packages from that...although compiling everything at once would take forever.

Yes, both ABS and the AUR are officially part of Arch...however, what's not officially supported are the things that you can do with them. The packages in the unsupported repository are just that, unsupported. You don't know who created them, you don't necessarily know what they do, they haven't been thouroughly tested, and you're probably on your own if it breaks something. Yes there are TUs and they can help make things safer for those of us that want to take advantage of the community/unsupported repos, but it's still not 'official'.

That's the very reason that <code>aurbuild</code> remains in unsupported instead of putting it in community...it's a powerful tool that should only be downloaded and used by people who fully understand what they are doing. Read: Why isn't aurbuild in community?. I actually agree with the side of having it in community, as it's not the tool that's dangerous, but what you can do with it that makes it so.

Arch is a binary and source distro in the sense that it gives you the tools to work with both types of packages, but at this point, the source packages still fall largely into the realm of unsupported, and that's why I think there's a clear separation. I guess I'm just fine with:

pacman -S foo   # for binary packages
makepkg -i      # for source packages

Perhaps adding a function to search the local /var/abs/ directory for the correct package to build and install would be a good feature request for <code>makepkg</code>?

Anyway, I guess we'll have to agree to disagree...

Arch Linux

#1 2006-02-28 19:00:35

Pacman Suggestion

#2 2006-02-28 19:06:23

Re: Pacman Suggestion

#3 2006-03-01 06:55:08

Re: Pacman Suggestion

#4 2006-03-01 15:01:51

Re: Pacman Suggestion

#5 2006-03-01 15:40:42

Re: Pacman Suggestion

#6 2006-03-01 16:11:05

Re: Pacman Suggestion

#7 2006-03-01 16:27:29

Re: Pacman Suggestion

#8 2006-03-01 16:27:52

Re: Pacman Suggestion

#9 2006-03-01 16:40:11

Re: Pacman Suggestion

#10 2006-03-01 18:15:34

Re: Pacman Suggestion

#11 2006-03-28 12:41:22

Re: Pacman Suggestion

#12 2006-03-29 18:54:01

Re: Pacman Suggestion

#13 2006-03-29 19:16:09

Re: Pacman Suggestion

#14 2006-03-29 19:19:47

Re: Pacman Suggestion

#15 2006-03-29 19:21:45

Re: Pacman Suggestion

#16 2006-03-29 19:22:32

Re: Pacman Suggestion

#17 2006-03-29 20:10:46

Re: Pacman Suggestion

#18 2006-03-29 21:06:41

Re: Pacman Suggestion

#19 2006-03-30 19:03:52

Re: Pacman Suggestion

#20 2006-03-30 21:19:56

Re: Pacman Suggestion

Board footer