4:17 p.m.
>>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
UB> Maybe 3d party package are not meant to be controlled by pui?
What do you suggest?
In short, what I suggest is the following:
1. modify PUI such that can install and most import **de-install**
lisp programs which are in xemacs package (pkg) Format (3rd party
packages)
WHY???
A. installing of pkg, even a 3rd party one like vm or x-symbol,
is a snap, no byte compiling, no path have to be set, however
B. *de Installation* is a horror because of the package
hierarchy. So one has to visit (inside the pkg directory) the
/etc, /info /lisp /man /pkginfo directory in order to delete
the relevant files. So we have the absurd situation that
installing a non-pkg lisp package is more difficult than a pkg
one, but *de Installation* is more complicated.
C. People may want to install non official pkg, since some of the
official ones are outdated.
2. Provide additionally information about the version number of the
original (non-pkg) distribution, something like:
Latest Installed
Package name Vers. Vers. Description
==============================================================
[snip]
- auctex 1.32 ----- Basic TeX/LaTeX support (o-version 10g)
^^^^^^^^^^^^^^^^
- bbdb 1.21 ----- The Big Brother Data Base (o-version 2.34)
^^^^^^^^^^^^^^^^
3. Explain under which conditions a 3rd party package enter the
circle of official Xemacs packages. I can only think here of
X-symbols which has been ignorated for years.
4. Provide a generic Makefile and Xemacs.rules for people interested
to build 3rd party packages. At the weekend I tried to write a
Makefile to generate a pkg, but it looks not this simple to
me. I am not sure that I understand your comment:
Stephen J. Turnbull writes:
That's right. It doesn't _support_ them, because compiling
Lisp
libraries outside of the source tree is likely to produce broken
libraries.
Let us take the following example, I untar x-symbol.src.tgz,
which
is not in pkg binball format, in /tmp. It's Makefile has the target
binball to generate a pkg. Now if you compile this in /tmp, the
resulting pkg is not _valid_?
5. Provide the Makefiles and Xemacs.rules of the official Xemacs
packages for the authors of the original non (pkg)packages, say
send such a Makefile for AUCTeX to David Karstrup, who now
maintains AUCTeX; I picked up this example because the Xemacs
released package is quite behind the official version. (I
remember a flame going between Stephen and Eli about the xemacs
package system, in which it is was pointed out that GNU emacs
shipped a two years old gnus! However now the case for AUCTeX
does not look much better!)
Here is my understanding of a packing systems in general.
A package system, such as RPM or deb (or Xemacs package) has the
following purposes:
i. It manages programs, installs, desinstalls and upgrades them, in a
certain Format (.rpm, .deb), by protocolling these steps in a
common system wide database.
ii. It check the dependencies necessary for this process.
iii. It allows to download and upgrade package provided by an official
distribution. (RPM offers this relatively lately and has been
widely critied for failure).
iv. It offers tools for producing such package, ie specifiy .spec files
for RPM
v. There exists one or more (g)ui for simplifying the process in point
1, such as xrpm or yast for the RPM system.
vi. There exist programs which simplify point 4, such as alien.
Name | RPM | Deb | xemacs-package
Packte Format | .rpm | .deb | .pgk
check dep | yes | yes | ?
Data base name | various in /var | ? | package-index.LATEST.pgp
spec file | .spec | ? | Xemacs.rules
(gui) | xrpm, yast | ? | pui
Here some details on what PUI could do for 3rd party pkg.
Like
M-x pui-add-install-directory-for-3rdparty-pack RET
~/mystuff/ RET
now pui reads a data base which is stored, say, at top of
prefix/xemacs/site-packages
named package-index.3party.pgp
M-x pui-list-packages-3rdparty RET
according to the content of this file, the packages located in
/tmp/ are flagged as not installed or installed:
Now the Installation process may start. *Advantage*: the
destallation is now ruled by the information in database in
prefix/xemacs/site-packages
Having such a feature would may be encourage more people to offer their
distribution as a Xemacs package.
David Kastrup, for example, prefers to spend his effort on
maintaining an autoconf script for preview-latex because his
preferred platform is GNU Emacs, which doesn't support packages.
Not really true: Preview latex (like bbdb) offers the possibility to
generate a a pseudo-package. That is during the make process, one can
specify the package directory and then the relevant files are copied
into it, however without makeing a pkg tar ball.
Uwe Brauer
9:49 p.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
On Mon, 2003-01-27 at 18:17, Uwe Brauer wrote:
B. *de Installation* is a horror because of the
package
hierarchy. So one has to visit (inside the pkg directory) the
/etc, /info /lisp /man /pkginfo directory in order to delete
the relevant files. So we have the absurd situation that
installing a non-pkg lisp package is more difficult than a pkg
one, but *de Installation* is more complicated.
Doesn't PUI or package-admin-delete-binary-package do this for you
(I'don't know, I don't remember using non-XEmacs packages)? See also
<http://www.xemacs.org/Documentation/packageGuide.html#Upgrading:Removing_...
2. Provide additionally information about the version number of
the
original (non-pkg) distribution, something like:
Look at the minibuffer while your mouse pointer hovers over a package in
the listing, or move the cursor into a row and hit 'i' (see Auth. V.
xxx). See also the bottom of the packages list buffer for "Useful
keys".
3. Explain under which conditions a 3rd party package enter the
circle of official Xemacs packages. I can only think here of
X-symbols which has been ignorated for years.
In short, an XEmacs package needs a maintainer. Convince the author to
help out or volunteer yourself. There are already too many packages
with xemacs-beta as the maintainer (volunteers welcome with these as
well), a good example of this would be the auctex case you refer to
below. See also
<http://www.xemacs.org/Develop/cvsaccess.html#committers>
4. Provide a generic Makefile and Xemacs.rules for people
interested
to build 3rd party packages. At the weekend I tried to write a
Makefile to generate a pkg, but it looks not this simple to
me.
If you're doing this anyway, why not suggest those packages as official
XEmacs ones and volunteer to maintain them? At the very least, all
proposals will be considered and replied to.
I am not sure that I understand your comment:
Stephen J. Turnbull writes:
> That's right. It doesn't _support_ them, because compiling Lisp
> libraries outside of the source tree is likely to produce broken
> libraries.
Let us take the following example, I untar x-symbol.src.tgz, which
is not in pkg binball format, in /tmp. It's Makefile has the target
binball to generate a pkg. Now if you compile this in /tmp, the
resulting pkg is not _valid_?
Stephen, could you fill in the blanks here, as well as on the "generic
Makefile and XEmacs.rules" question?
5. Provide the Makefiles and Xemacs.rules of the official
Xemacs
packages for the authors of the original non (pkg)packages, say
send such a Makefile for AUCTeX to David Karstrup, who now
maintains AUCTeX; I picked up this example because the Xemacs
released package is quite behind the official version.
David has explicitly said no to maintaining the XEmacs auctex package
[1]. And nobody else has volunteered. So, it might happen
someday(tm). Personally, I don't want to touch it because I don't use
or know TeX; I'm limited to applying obvious bugfixes to it only.
Name | RPM | Deb | xemacs-package
Packte Format | .rpm | .deb | .pgk
check dep | yes | yes | ?
There is limited support for dependencies (they're build time ones only,
but better than nothing at runtime as well). PUI also handles these,
select a package for installation and hit 'r' or use the "Packages->Add
required" menu.
FYI, there's a thread [2] on xemacs-design about possibly rewriting at
least parts of the packages system.
[1] <http://list-archive.xemacs.org/xemacs-beta/200212/msg00262.html>
[2] <http://list-archive.xemacs.org/xemacs-design/200301/msg00043.html>
--
\/ille Skyttä
scop at xemacs.org
5:50 a.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> Doesn't PUI or package-admin-delete-binary-package do this
Ville> for you (I'don't know, I don't remember using non-XEmacs
Ville> packages)? See also
Ville>
<http://www.xemacs.org/Documentation/packageGuide.html#Upgrading:Removing_...
package-admin-delete-binary-package is non-interactive, thus doesn't
count as part of PUI. That is probably easily fixed, not by changing
that function but by wrapping it in something to give it sane
arguments and get confirmation, etc, in package-ui.el.
If you look at package-ui.el, you'll see that list-packages
unfortunately uses package-get-base for the package list itself, and
does not consult packages-package-list to find out about local
packages. This is probably also easily fixed. I think that for
installation of 3rd party packages, we just set them up the way
Pre-Releases is set up. The packager provides a local
package-get-base list, and Tools | Packages | Sites needs a way to set
up 3rd party sites.
I think these are both worthwhile projects. They're several months
away (maybe 3rd quarter?) on my personal list, though. Before that I
would work on alternative transports (http and TRAMP, at least) for
downloads.
I am not sure that I understand your comment:
Stephen J. Turnbull writes:
> That's right. It doesn't _support_ them, because compiling Lisp
> libraries outside of the source tree is likely to produce broken
> libraries.
Let us take the following example, I untar x-symbol.src.tgz, which
is not in pkg binball format, in /tmp. It's Makefile has the target
binball to generate a pkg. Now if you compile this in /tmp, the
resulting pkg is not _valid_?
Ville> Stephen, could you fill in the blanks here, as well as on
Ville> the "generic Makefile and XEmacs.rules" question?
Sure.
1. "Broken packages" means "we cannot guarantee there will be no bugs
if you do this", in fact, you can be pretty sure that you will run
into bugs (the always inscrutable "can't call macros from compiled
Lisp" variety).
2. The resulting package is probably not "valid." The package tools
may not install it correctly, they need a MANIFEST.$package in the
pkginfo directory to uninstall it, and the odds are pretty high that
it will not provide a conformant auto-autoloads library and other meta
information. The easiest way to get that stuff is
cvs checkout package-control
create packages/site-packages, drop the package files in a
subdirectory of packages/site-packages, and create appropriate
package-info.in and Makefile. In site-packages/Makefile you need
exactly two lines:
PACKAGES = <subdirectories containing packages here>
include ../iterate.rules
None of this is well-tested; it did work for me many moons ago, but
there has been a lot of hacking on *.rules since then.
3. There are generic control files as well as documentation of their
various options in C-h i g (lispref) Creating Packages RET.
packages/XEmacs.rules has no user-servicable parts; look in
packages/Local.rules for site configuration. This is documented in a
sibling node, as well as copious comments in Local.rules.template.
Name | RPM | Deb | xemacs-package
Packte Format | .rpm | .deb | .pgk
check dep | yes | yes | ?
Ville> There is limited support for dependencies (they're build
Ville> time ones only, but better than nothing at runtime as
Ville> well).
The issue of dependencies is extremely difficult. I am not at all a
fan of the dependency systems implemented by dpkg or RPM.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
11:30 p.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
Hello
I think I wrote most of the relevant sites you mentioned, before going
to politics an important technical question:
1. In my understanding a 3rd party pkg could be installed either in
~/.xemacs/xemacs-packages
OR in
/prefix/lib/xemacs/site-packages
(my experience is entirely based on x-symbols, which however is
recommended to be installed in ~/.xemacs/xemacs-packages).
Now I read to my surprise in the documentation
</P>
<DT><VAR>XEMACS_STAGING = ${XEMACS_PACKAGES_BASE}/../Packages</VAR>
<DD>Set this to where you want normal packages to be
installed to.
So here I have to chose one of the possibility mentioned above.
furthermore
<DT><VAR>symlink =</VAR>
<DD>Set this to 't' if you want to do a "\run in place""
Setting this doesn't work well with 'make bindist'
<P>
This seems to be too bad. If I understand correctly a maintainer of a
3rd package has to make his decision where to install the package and
there are pro and cons for either solution.
Stephen J. Turnbull writes:
package-admin-delete-binary-package is non-interactive, thus
doesn't
count as part of PUI. That is probably easily fixed, not by changing
that function but by wrapping it in something to give it sane
arguments and get confirmation, etc, in package-ui.el.
If you look at package-ui.el, you'll see that list-packages
unfortunately uses package-get-base for the package list itself, and
does not consult packages-package-list to find out about local
packages. This is probably also easily fixed. I think that for
installation of 3rd party packages, we just set them up the way
Pre-Releases is set up. The packager provides a local
package-get-base list, and Tools | Packages | Sites needs a way to set
up 3rd party sites.
If this is the case I strongly to suggest to release this as soon as
possible, could greatly enhance the production of 3rd party package,
because up to now there is the de-instalation problem.
1. "Broken packages" means "we cannot guarantee there
will be no bugs
if you do this", in fact, you can be pretty sure that you will run
into bugs (the always inscrutable "can't call macros from compiled
Lisp" variety).
Ok
Ville Skyttä writes:
> 3. Explain under which conditions a 3rd party package enter the
> circle of official Xemacs packages. I can only think here of
> X-symbols which has been ignorated for years.
In short, an XEmacs package needs a maintainer. Convince the author to
help out or volunteer yourself. There are already too many packages
with xemacs-beta as the maintainer (volunteers welcome with these as
well), a good example of this would be the auctex case you refer to
below. See also
<http://www.xemacs.org/Develop/cvsaccess.html#committers>
Given the explanation of Stephen, the maintainer, even if he/she
provides a packages has to re generate it with slightly modified
Makefiles.
As for x-symbol, I try to contact Christoph.
As for auctex and preview latex.
David has explicitly said no to maintaining the XEmacs auctex
package
[1]. And nobody else has volunteered. So, it might happen
someday(tm). Personally, I don't want to touch it because I don't use
or know TeX; I'm limited to applying obvious bugfixes to it only.
I know TeX but it seems to me more a question of lisp, which I might
not know sufficiently, in any case I volunteer for auctex. I think
this is important enough especially now that there seems fresh air in
the development by David, and because preview-latex badly needs a
recent version of auctex. (As for preview-latex we will see, since
this is already in pseudo pkg form)
As a starting point could you send me the relevant makefiles and rules
files you have used so far, this would greatly speed up my learning
curve.
Uwe
7:22 a.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> So here I have to chose one of the possibility mentioned
Uwe> above.
XEMACS_STAGING seems to be misdocumented. I'll get back to you on
that.
symlink=t is irrelevant to package distribution as tarballs. You
should physically copy the files to a clean staging directory for that.
Uwe> This seems to be too bad. If I understand correctly a
Uwe> maintainer of a 3rd package has to make his decision where to
Uwe> install the package and there are pro and cons for either
Uwe> solution.
The maintainer of a 3rd party package has no choice about where to
install the package. It's the local admin's call. Ie, the minimal
package `foo' will contain in the tarball
lisp/
lisp/foo.el
lisp/foo.elc
lisp/auto-autoloads.el
lisp/auto-autoloads.elc
pkginfo/
pkginfo/MANIFEST.foo
No "xemacs-packages/". Where those subdirectories reside is up to the
installing admin, not the package maintainer.
Uwe> As a starting point could you send me the relevant makefiles
Uwe> and rules files you have used so far, this would greatly
Uwe> speed up my learning curve.
cvs co package-control
cvs co auctex
gets you what you need. You need everything in package-control, and
if you're going to be maintainer you'll need to be using CVS anyway.
If there are multiple Makefiles in the xemacs-packages/auctex
directory, the one named "Makefile" is ours. The other administrative
file you need is package-info.in. You probably don't need to change
that at all.
Note that you probably cannot build auctex that way. See the REQUIRES
variable in Makefile for other packages whose sources must be present
in order to build AUC-TeX. (Note: this restriction is not imposed by
the package system for our convenience. It is imposed because
experience has shown that building packages with anything other than
an up-to-date tree greatly increases the likelihood of buggy binary
packages being released. Relaxing it would require a tool capable of
analyzing all the possible ways that inline code could be imported to
the package you're primarily interested in---and every function call
is a suspect because of the autoloads feature.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:02 p.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> So here I have to chose one of the possibility mentioned
Uwe> above.
XEMACS_STAGING seems to be misdocumented. I'll get back to you on
that.
symlink=t is irrelevant to package distribution as tarballs. You
should physically copy the files to a clean staging directory for
that.
Uwe> This seems to be too bad. If I understand correctly a
Uwe> maintainer of a 3rd package has to make his decision where to
Uwe> install the package and there are pro and cons for either
Uwe> solution.
The maintainer of a 3rd party package has no choice about where to
install the package. It's the local admin's call. Ie, the minimal
package `foo' will contain in the tarball
lisp/ lisp/foo.el lisp/foo.elc lisp/auto-autoloads.el
lisp/auto-autoloads.elc pkginfo/ pkginfo/MANIFEST.foo
No "xemacs-packages/". Where those subdirectories reside is up to the
installing admin, not the package maintainer.
That was my understanding so far! In other words a 3rd party package
*can* be untarred, *either* in ~/.xemacs/xemacs-packages
*or* in
/prefix/lib/xemacs/site-packages
If so to include x-symbol, which is already in pkg format and is
tested for almost 2 years, would practically just mean to copy it in
the main package tree. I am pointing this out, because before
contacting Christoph I want to understand what has to be done.
Usually it was said CVS access and an appropriate Makefile,
Xemacs.rules file etc, but x-symbol is exceptional, since it is
already in pkg format. So it looks to me like to reinvent the wheel if
one does all this Makefile, rules thing.
However there is still something I fail to understand
in cHristophs Makefile for the source distribution there is line:
PACKAGEDIR = $(HOME)/.xemacs/xemacs-packages
What is this good for, if it does not matter, that the PACKAGEDIR
could also be
/prefix/lib/xemacs/site-packages
Thanks
Uwe
2:30 a.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
UB> If so to include x-symbol, which is already in pkg format and is
UB> tested for almost 2 years, would practically just mean to copy it in
UB> the main package tree. I am pointing this out, because before
UB> contacting Christoph I want to understand what has to be done.
UB> Usually it was said CVS access and an appropriate Makefile,
UB> Xemacs.rules file etc, but x-symbol is exceptional, since it is
UB> already in pkg format. So it looks to me like to reinvent the wheel if
UB> one does all this Makefile, rules thing.
I will set up x-symbol, and with Ville's OK, add it to the XEmacs
packages CVS repository. Once it is all set up then we'll try to
encourage you to take over as its maintainer in our CVS.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
10:37 a.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
On Sat, 2003-02-01 at 04:30, Steve Youngs wrote:
I will set up x-symbol, and with Ville's OK, add it to the
XEmacs
packages CVS repository. Once it is all set up then we'll try to
encourage you to take over as its maintainer in our CVS.
Thanks for the offer, Steve, but maintainership questions need to be
sorted out before any new package hits our CVS. Uwe, Steve, how's about
it?
--
\/ille Skyttä
scop at xemacs.org
1:07 a.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
|--==> "VS" == Ville Skytt <Ville> writes:
VS> On Sat, 2003-02-01 at 04:30, Steve Youngs wrote:
>I will set up x-symbol, and with Ville's OK, add it to the
XEmacs
>packages CVS repository. Once it is all set up then we'll try to
>encourage you to take over as its maintainer in our CVS.
VS> Thanks for the offer, Steve, but maintainership questions need to be
VS> sorted out before any new package hits our CVS. Uwe, Steve, how's about
VS> it?
Yeah, sure, I'll maintain it for now. Uwe, if you want the honour of
this role, it's all yours. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:18 p.m.
New subject: PUI manages 3rd party packages: more RPM or DEB like
On Sun, 2003-02-02 at 03:07, Steve Youngs wrote:
>>I will set up x-symbol, and with Ville's OK, add it to
the XEmacs
>>packages CVS repository. Once it is all set up then we'll try to
>>encourage you to take over as its maintainer in our CVS.
VS> Thanks for the offer, Steve, but maintainership questions need to be
VS> sorted out before any new package hits our CVS. Uwe, Steve, how's about
VS> it?
Yeah, sure, I'll maintain it for now. Uwe, if you want the honour of
this role, it's all yours. :-)
Cool! Go ahead and add it, Steve.
--
\/ille Skyttä
scop at xemacs.org
7964
days inactive
7970
days old
9 comments
4 participants
participants (4)
-
Stephen J. Turnbull -
Steve Youngs -
Uwe Brauer -
Ville Skyttä