[pacman-dev] Add a "provided" field in PKGBUILD
Dan McGee
dpmcgee at gmail.com
Mon Mar 15 00:10:27 CET 2010
On Wed, Mar 10, 2010 at 6:08 PM, Diego Ferigo <dieghen89 at gmail.com> wrote:
> Hi guys!
> I have a propose for pacman/makepkg...Now I'm going to explain my idea...
>
> In AUR there are some problems regarding the dependencies
> management...Particularly when a package, that from this moment I'll call *
> subpackage*, is a part of another package, that I'll call
> *main_package*(example gnome-python-desktop and python-wnck).
>
> It would be nice if the maintainer of the subpackage could add a field *
> provided* (or another name), that point out to the package that contains
> it...
>
> Obliviously the 2 packages go in conflict because they share the same
> files..Now the solution is to add a provides field in the main_package, done
> by his maintainer...The maintainer of the main_package has to add a new
> object in provides array, every new subpackage created.
>
> This new field, provided, get the main_package maintainer off to this
> change, and it give the duty to the subpackage maintainer. I opened a bug
> some weeks ago, requesting the add of provides= in a extra package, but the
> problem remained unsolved because AUR and repos are 2 different things.
>
> This method can solve a lot of dependencies problem that happened (to me) in
> this period...And it is more kiss imho....
>
> What do you think?
I'm not sure I agree. What we have now works well for almost all
situations and this new field would add yet some more trickyness to
the mix- we already have provides and conflicts, I'd rather not have
another.
It seems like what we have here is a problem that is best solved at
the packaging level, by either of the packages, rather than by adding
another option. What good is it to have half of an [extra] package in
the AUR?
-Dan
More information about the pacman-dev
mailing list