Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 98522 - Fix openclipart-0.15 ebuild and future releases
Summary: Fix openclipart-0.15 ebuild and future releases
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Desktop Misc. Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-09 18:21 UTC by Jon Phillips
Modified: 2009-01-17 20:41 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Phillips 2005-07-09 18:21:43 UTC
The ebuild for openclipart-0.15 is in the category x11-misc and should be in
media-gfx, as the project is a collection of vector graphics. 

Also, we are hoping that the installed path could be
/usr/share/clipart/openclipart-VERSION_NUMBER and then also have a symlink from
/usr/share/clipart/openclipart-VERSION_NUMBER to /usr/share/clipart/openclipart
(which is where releases are currently installed).

There are differences between releases so we don't want to overwrite explicity
old releases. However, overwriting old releases could be a good USE flag.

Also, here is the ebuild that our devs. have been referencing, so maybe some of
the features from it could be merged with the new one in portage:
http://www.premolo.com/~gavin/portage/overlay/media-gfx/openclipart/

Reproducible: Always
Steps to Reproduce:
Comment 1 Jon Phillips 2005-07-09 18:22:53 UTC
Crap, this should be assigned to desktop-misc@gentoo.org. I forgot to do this
and now I cannot with my current permissions on this bugzilla.

Thanks!
Comment 2 Jon Phillips 2005-07-09 18:28:30 UTC
Also, why is the openclipart-0.15 ebuild architecture dependent? Anyone system
Gentoo supports should be able to use it. We have users asking for ~amd64
support, and it might as well support as many systems as possible, as the
contents of the package are files like svg, png, and txt.

Thanks!
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2005-07-10 01:16:22 UTC
(In reply to comment #2)
> We have users asking for ~amd64 support

This ebuild is marked ~amd64, so I don't understand what's the problem here.
Comment 4 Jonathan Smith (RETIRED) gentoo-dev 2005-07-10 07:33:26 UTC
(In reply to comment #2)
> Also, why is the openclipart-0.15 ebuild architecture dependent? Anyone system
> Gentoo supports should be able to use it. We have users asking for ~amd64
> support, and it might as well support as many systems as possible, as the
> contents of the package are files like svg, png, and txt.

take a look here: http://packages.gentoo.org/search/?sstring=openclipart

personally, i can only mark packages on x86 and amd64. it is possible that i
might be able to mark a few things sparc in the future, but that is, well, in
the future.

every ebuild has to be tested on every arch before it is marked with that arch,
no matter what the ebuild does or contains.
Comment 5 Jonathan Smith (RETIRED) gentoo-dev 2005-07-10 07:42:27 UTC
as for the catagory, i personally don't care. the origional bug was filed to
desktop-misc@g.o, and most of our packages go in x11-misc. if the media herds
will be willing to take over the package, then it can be moved. until then, i'd
like to keep it in x11-misc.

as for symlinking and slotting... i don't see the point. afaik, the only
difference between releases is a few scripts and an _increase_ in the number of
images. that makes slotting somewhat pointless.

even more use flags also seems pointless. it already has 6 rather cryptic ones...

the ebuilds you reference also undo many of the features that the one in portage
contains... if you would like to create a diff against that of exactly what you
would like to add/subtract, i would be willing to look. however, i rather like
the current ebuild

one more thing... if you want openclipart to be available on more platforms,
file a new bug entitled "x11-misc/openclipart arch testing" and CC all the
relevent platforms. be sure to include only _relevent_ platforms... i doubt arm
will want an ebuild that creates 7390245872039458263409 huge image files for no
reason (as an example)

if there is a good reason to do any of this which i am somehow missing, either
email me or reopen the bug