gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Gentoo ebuild done


From: David Grant
Subject: Re: [Gnumed-devel] Gentoo ebuild done
Date: Fri, 21 Jul 2006 09:54:37 -0700

On 7/21/06, Karsten Hilbert <address@hidden> wrote:
On Thu, Jul 20, 2006 at 03:50:04PM -0700, David Grant wrote:

> >> Click on the .ebuild file and look at it if you are curious. Notice how
> >> simple it is compared to debian.
> >
> >"apt-get install gnumed-client" seems just as simple
>
> Well I was referring to the simplicity of the package itself. Compare
> the ebuild file to a debian deb package.
Aha, I see. I guess you are the one in the know on that one.
Good to know its fairly easy to do. Do you want me to mail
you a prerelease tarball to get a feel for how (much) it
changed ?

> There are many packages that use distutils that are not python
> "add-ons."
Sounds interesting. Could you point out some so we might
take a look at how they handle their installation ?

> Actually I don't really know what you mean by "python
> add-on."
By that I mean packages which add a few modules to Python
and maybe a script or two to call one of the modules
directly (top-level).

The difference I see in that is when a package starts
providing documentation (to go in /usr/share/doc/...),
configuration (to go in /etc/... or ~/.package/...), binary
files such as bitmaps (to go in /usr/lib/package/...) or all
sorts of content (HTML, ASCII) (DermTool, official vacc
schedule docs).

> And all python packages in gentoo go into
> /usr/lib/python2.4/site-packages whether they use distutils or not.
Sure, the Python parts do go there. They did so in 0.1, too.
I fully agree.

> Standard procedure is to put all the *.py stuff there and if an
> executable in the $PATH is needed a script is put in /usr/bin that
> runs python.
Yep. The thing is that it doesn't stop there. There are more
files than that to install in their proper location. And
that's where distutils start to fall down (and rightly so,
of course, since they are not intended to do that).

The probably "most proper" way is to call distutils from
ebuild/apt-get/whatnot to install the Python *part* of
GNUmed. However, that's in an ideal world. It doesn't really
matter too much at this moment how things find their proper
place, I suppose.

I think you hit the nail on the head on all points except that I
thought distutils could install files to other locations as well like
/usr/share/doc/<packagename> and /usr/share/<packagename>. You might
be right, maybe distutils can't. In which case a gentoo ebuild calls
'python setup.py install' and then installs docs and images, etc..
manually. In that case, the ebuild doesn't become much simpler...
which would explain why many large python applications don't use
distutils as well...  which is fine too..


> The build is grabbing the following URL:
> http://download.savannah.gnu.org/releases/${PN}/GNUmed-client.${PV}.tgz
>
> where ${PN} is the packagename (determined from the ebuild file name),
> and ${PV} is the version. So:
> http://download.savannah.gnu.org/releases/gnumed/GNUmed-client.0.1.tgz
I see. Yeah, the build would start to grab 0.2 when it
becomes available. However, the internal structure did
change so the subsequent build *process* might fall down ?

Yes, that's right. Often gentoo ebuild writers will just change the
version number of the ebuild filename (a version bump) and see if it
works. If it doesn't then they look to see what changed... But the
real way to do it is probably to diff the two tar balls, look at
changelogs, etc... to see if anything changed.

Dave


Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel



--
David Grant




reply via email to

[Prev in Thread] Current Thread [Next in Thread]