View previous topic :: View next topic |
Author |
Message |
audiodef Watchman
Joined: 06 Jul 2005 Posts: 6656 Location: The soundosphere
|
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sun Mar 18, 2018 12:33 pm Post subject: |
|
|
Only use to build, so none if you 100% trust the dev has done a good work on that ebuild.
But before you go into some automation to remove package from DEPEND, it would be a bad idea to do that, as per example any C program should depends on gcc to build, and removing gcc won't make any trouble to run that program later ; but you'll be really unhappy to have gcc removed
I'm also not quiet sure how an ebuild should be made with a package that is both DEPEND and RDEPEND (like glibc, that a program need to build and also to run), logically it should be set on both, but if a dev just set it as DEPEND, removing glibc won't again be a good idea).
Are you trying to make gentoo studio on diet? |
|
Back to top |
|
|
audiodef Watchman
Joined: 06 Jul 2005 Posts: 6656 Location: The soundosphere
|
Posted: Sun Mar 18, 2018 12:47 pm Post subject: |
|
|
Ha, no, I'm messing with the idea of quickpkg'ing firefox so I can have a distributable bin for it with jack support. It pulls in clang and rust, and those two alone take up most of the build time, even on a new-fast machine. So if I need to include clang and rust anyway, there's no point to haxxing with quickpkg and firefox.
This makes me think though, that it would be so much easier if it was a universally followed standard to put anything in RDEPEND that's a run-time dep, even if it's also a build dep, or to put in RDEPEND anything that is required by the system in general after building a specific package. Or perhaps at some point if an SDEPEND was created to require non-removable system build deps, and having an option to rm DEPEND pkgs post-install for those wanting slim systems.
EDIT: Neddy answered my musings pretty well. _________________ decibel Linux: https://decibellinux.org
Github: https://github.com/Gentoo-Music-and-Audio-Technology
Facebook: https://www.facebook.com/decibellinux
Discord: https://discord.gg/73XV24dNPN
Last edited by audiodef on Sun Mar 18, 2018 12:50 pm; edited 2 times in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54588 Location: 56N 3W
|
Posted: Sun Mar 18, 2018 12:48 pm Post subject: |
|
|
audiodef,
The DEPENDS and RDEPENDS in ebuilds are usually incomplete.
The @system set is always assumed to be available, so members of the @system set only appear in ebuids if versions matter.
These unlisted dependencies serve to break most of the circular dependencies that would otherwise arise.
As krinn says, file bugs if you remove a build time dependency and something breaks. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22723
|
Posted: Sun Mar 18, 2018 4:29 pm Post subject: |
|
|
audiodef wrote: | Ha, no, I'm messing with the idea of quickpkg'ing firefox so I can have a distributable bin for it with jack support. It pulls in clang and rust, and those two alone take up most of the build time, even on a new-fast machine. So if I need to include clang and rust anyway, there's no point to haxxing with quickpkg and firefox. | Unless precluded by license, you could instead extend your scheme to quickpkg all three. Users who had a compatible clang/rust installed could skip installing the tbz2 archives of those packages and go direct to installing the tbz2 of Firefox. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54588 Location: 56N 3W
|
Posted: Sun Mar 18, 2018 4:39 pm Post subject: |
|
|
audiodef,
... and rust needs cargo .... and cargo ne .....
Careful with distributing binaries of firefox. You need to build it with USE=bindist, for sure.
You may not be able to call it firefox either. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|