pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Subversion without python and/or Ruby?



Eric Gillespie wrote:
>>      Even worse -- the subversion meta package insists on "building" Sun's
>>   JDK. Anyone have any luck installing that on a NetBSD/amd64 system?
>>
>>      Subversion, Python, Ruby, et. al. Are extremly portable -- Java is
>>   not. I see no reason to disable the subversion meta package for all the
>>   non-i386 users out there.
>>
>>      Subversion already uses the options framework -- wouldn't it make
>>   sense to add Java as an option which isn't enabled by default?
> 
> devel/subversion is not some random subset of Subversion chosen
> by the packager; it depends on all Subversion (well, all that
> we've gotten around to packaging yet ;-> ; I think it's complete,
> now that I've packaged javahl).  If you want specific components,
> install them separately.  Maybe all you want is subversion-base.

   Let's look at it from an pkgsrc-view, rather than a single package.

   I'm using NetBSD/amd64. It's not an uncommon architecture/port. I
would assume that the packages in pkgsrc would cater towards being cross
platform (just a guess, extrapolated by the number of platforms pkgsrc
supports, and all the work being put into patches to make it even more
platform friendly), and being one who runs NetBSD/amd64, I assumed that
meta packages which could easily be cross platform-friendly, without
ruining it for everyone else, would be so.

   If it were up to me, highly non-portable dependencies would be
disabled by default in pkgsrc through the options framework, and the
documentation would specify that.

   You, and others, have suggested that I install subversion-base and
the python plugin manually. Obviously, that's what I've had to revert to
when I noticed that the builds broke. But that's not the point -- I
could have downloaded it and built it myself if "getting an executable"
was what I was getting at. The point is that locking out a large number
of users from a meta package because of changes which are relevant to
0.1% of the users who can still use the meta package is a Bad Idea(tm).

   If Gnome and KDE incorporate some meaningless (for the vast majority
of users) Java-program, do we break meta-pkgs/gnome and meta-pkgs/kde
for all those users who can not get Java built on their systems?

   ..or could we at least wait until Sun has open sourced all of their
java-stuff, and it has been imported into pkgsrc?


   Try seeing it from my perspective: I've never run into anything like
this in pkgsrc before. Ihough it may seem minor change to you [the
average i386 or sparc user, that is], to me it's a huge shift in priorities.

-- 
Kind regards,
Jan Danielsson


Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index