Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 26575 - Request for a cvs ebuild for the mono project.
Summary: Request for a cvs ebuild for the mono project.
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: dotnet
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-13 15:21 UTC by Slava Akhmechet
Modified: 2003-08-23 13:31 UTC (History)
0 users

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 Slava Akhmechet 2003-08-13 15:21:56 UTC
We have a complete .NET application and are actively working on porting it to 
mono. Since we often encounter bugs in mono that the mono team fixes but do not 
touch mono code ourselves, we have to use anonymous cvs access. I am responsible 
for porting our application to mono but do not yet feel confident enough to make 
a cvs ebuild. It would be nice if one of the maintainers could take the time to 
make one.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Rainer Größlinger (RETIRED) gentoo-dev 2003-08-13 15:37:00 UTC
Hi,

first, you might want to make sure it runs on portable .net as well ;-)
second, I doubt there are any chances for a mono-cvs ebuild, but rather for the daily snapshots they are doing for 2 weeks or so now...
(see http://go-mono.com/daily)
Although it shouldn't make that much difference on daily-snapshots in contrast to a cvs ebuild;)

I am sure you soon hear from foser or tberman, I am mainly responsible for portable .net

For various reasons we keep the number of cvs ebuilds as low as possbible, especially where they aren't really necessary ;)

btw: dotgnu pnet cvs ebuilds are available at
http://dev.gentoo.org/~scandium/dotgnu-pnet-cvs/
Comment 2 Slava Akhmechet 2003-08-13 15:51:25 UTC
For our purposes there is no difference between daily snapshots and a cvs ebuild. Thanks for mentioning it, I wasn't aware of the daily snapshots.
I will look into DotGNU portable .net project. For some reason I knew nothing about its existance.

Thanks for giving me valuable information.
Comment 3 foser (RETIRED) gentoo-dev 2003-08-14 03:38:06 UTC
I personally see no reason for mono cvs ebuilds, given that releases are done quite often on a regular basis. It should be easy to adapt to current ebuilds to work with the daily snapshots Scandium mentions and writing a simple cvs ebuild isn't that complicated either if you really need it. I'm not sure there are still good examples in the live tree, otherwise we could provide you with some examples of cvs ebuilds to base it on.
Comment 4 Slava Akhmechet 2003-08-14 12:44:33 UTC
Thanks for your reply.
It seems that cvs ebuilds are superior to daily snapshot ebuilds because they do not require a full download of the source code every time the software is updated. In any case, I will consult developer documentation and will use the forums if I need help.
Comment 5 Todd Berman (RETIRED) gentoo-dev 2003-08-15 10:16:43 UTC
In general a live CVS ebuild is a bad idea, and in this specific case, its a horrible idea.

the mono class library and internal mono runtime are undergoing rapid changes. Sometimes with cvs what it takes to compile are a bit different than another day.

For example, there are times when the corlib needs to be compiled and installed before mcs, which is not the default build order.

Other times certain assembly's require compilation outside of build order.

And believe it or not, there are also times when its impossible to compile it with your current runtime and class library and you *have* to go download a monocharge.

As far as I know the mono daily builds, and in particular the monocharge (executables and class librarys) are fairly small, and if bandwidth is your only reason for going with cvs, I recommend avoiding an ebuild and doing it by hand.
Comment 6 Todd Berman (RETIRED) gentoo-dev 2003-08-23 13:31:20 UTC
closing this