Presently it's the nekoware standard to have release notes an optional install. I have found that they often have relevant information, so now I do "custom install" every time and check out what's going in. That's probably a good idea anyway but the apt-get and rpm immigrants most likely don't do that. I can see the reasoning - people with Indigos or Indys with small drives might want to save space, but the release notes are pretty tiny ... Should we change the default on release note installation, or does no one care ?
SGI: Development
proposed change to nekoware ?
not that i use it anymore, but when i was still packaging for nekoware, i found that the release notes were actually pretty important reads. thus my vote is clear.
The Bandito wrote: In a few years, no doubt, you'll be able to buy a computer,
software and operating system that will match the capabilities
of your current Amiga at about the price you paid for the
Amiga way back when. But you can smile to yourself, knowing
that you were touching the future years before the rest of
the world. And that other computers and operating systems
will do with brute force what the Amiga did years before with
grace, elegance and style.
Eroteme.ch - my end of the internet...
Missing option: "Dog ate my release notes".
R.
R.
死の神はりんごだけ食べる
開いた括弧は必ず閉じる -- あるプログラマー
J5600, 2 x Mac, 3 x SUN, Alpha DS20E, Alpha 800 5/550, 3 x RS/6000, Amiga 4000 VideoToaster, Amiga4000 -030, 733MHz Sam440 AmigaOS 4.1 update 1.
Sold:
Tandem Himalaya S-Series Nonstop S72000 ServerNet.
Twitter @PymbleSoftware
Current Apps (iOS) -> https://itunes.apple.com/au/artist/pymb ... d553990081
(Android) https://play.google.com/store/apps/deve ... +Ltd&hl=en
(Onyx2) Cortex ---> http://www.facebook.com/pages/Cortex-th ... 11?sk=info
(0300s) Minnie ---> http://www.facebook.com/pages/Minnie-th ... 02?sk=info
Github ---> https://github.com/pymblesoftware
開いた括弧は必ず閉じる -- あるプログラマー
J5600, 2 x Mac, 3 x SUN, Alpha DS20E, Alpha 800 5/550, 3 x RS/6000, Amiga 4000 VideoToaster, Amiga4000 -030, 733MHz Sam440 AmigaOS 4.1 update 1.
Sold:
Tandem Himalaya S-Series Nonstop S72000 ServerNet.
Twitter @PymbleSoftware
Current Apps (iOS) -> https://itunes.apple.com/au/artist/pymb ... d553990081
(Android) https://play.google.com/store/apps/deve ... +Ltd&hl=en
(Onyx2) Cortex ---> http://www.facebook.com/pages/Cortex-th ... 11?sk=info
(0300s) Minnie ---> http://www.facebook.com/pages/Minnie-th ... 02?sk=info
Github ---> https://github.com/pymblesoftware
PymbleSoftware wrote: Missing option: "Dog ate my release notes"
Fixed. Thanks
How about an in-between option
If the release notes only contain information about building the package, then they are probably not interesting to most people, so it's OK to not install them by default.
But if they contain information that is necessary to set up the package (e.g. adding a user for sshd or similar), then they should be installed by default. In this case, if extra action is required from the user, I would also suggest adding an "inst.README" file into the tardist, so swmgr pops up a message with its contents.
If the release notes only contain information about building the package, then they are probably not interesting to most people, so it's OK to not install them by default.
But if they contain information that is necessary to set up the package (e.g. adding a user for sshd or similar), then they should be installed by default. In this case, if extra action is required from the user, I would also suggest adding an "inst.README" file into the tardist, so swmgr pops up a message with its contents.
I like what ShadeOfBlue suggested. That's a well though out proposal, especially his note about inst.README.
Sun SPARCstation 20, Blade 2500
HP C8000
jpstewart wrote: I like what ShadeOfBlue suggested. That's a well though out proposal, especially his note about inst.README.
<aol mode> Me, too ! </aol mode>
There are some SGI-delivered tardists that automatically pop up the release notes .. does anyone know how that is done ?
Let me rephrase that ... does anyone here know how that is done and are they willing to give a short lesson ?
Yes, its done by having having the relnotes in a standard place and format. They are compiled like man pages.
As the manpage for relnotes says
as an example from my somtk project
As the manpage for relnotes says
Code: Select all
FILES
/usr/relnotes/<product>/TC table of contents file for <product>
/usr/relnotes/<product>/ch*.z release notes for <product>
as an example from my somtk project
Code: Select all
/usr/relnotes/somtk
bash-4.0$ ls
TC ch1.z ch2.z ch3.z ch4.z ch5.z
bash-4.0$ cat TC
chap title
1 Introduction
2 Installation
3 Environment
4 License for somFree
5 License for cpp from lcc
Land of the Long White Cloud and no Software Patents.
I'll also vote for the automatically displayed release notes for information critical for the installation or operation. Some SGI/commercial packages just echo some additional information to the console or the log pane in swmgr, but that's just too easy to overlook. Any patch/configure/build/dependency info etc. can still go into an optional file in /usr/nekoware/relnotes.
While we are discussing changes, I think manpages should always go into /usr/nekoware/man, not share/man, and patches into /usr/nekoware/patches, not /patch. There's also a doc/ and docs/ subdirectory, and we should standardize on at most one of those.
While we are discussing changes, I think manpages should always go into /usr/nekoware/man, not share/man, and patches into /usr/nekoware/patches, not /patch. There's also a doc/ and docs/ subdirectory, and we should standardize on at most one of those.
Shades and canavan's suggestions sound good to me, FWIW. Including directory cleanup/standardization.
Then?
...
Now?
-
+MLA
...
Other:
DEC
Sun
,
DG AViiON
,
NeXT
...
Now?
-
+MLA
...
Other:
DEC
Sun
,
DG AViiON
,
NeXT
canavan wrote: While we are discussing changes, I think manpages should always go into /usr/nekoware/man, not share/man
The same logic should probably be applied to texinfo pages. I've noticed some packages put them in /usr/nekoware/info and others in /usr/nekoware/share/info. If manpages should go in man rather than share/man, then info pages should be in /usr/nekoware/info rather than share/info. That would mean that the neko_texinfo package would have to be configured to look there. I think that the info utility looks in share/info by default. (Or rather, I think that GNU standards specify share/man and share/info by default for their stuff.)
Note that the use of man vs. share/man and info vs. share/info is due to differences in the source packages' defaults. Some install into PREFIX/man and PREFIX/info while others install into PREFIX/share/man by default. It will be necessary to pass --mandir=... and --infodir=... (or perhaps just --datarootdir=/usr/nekoware) options to the configure script (after the --prefix option as described in http://www.nekochan.net/wiki/Packaging_Software#Building_the_Software ) to get consistent behaviour across all source packages. If that's what people want.
Sun SPARCstation 20, Blade 2500
HP C8000
... and N32 shared libraries should go into /usr/nekoware/lib32
Land of the Long White Cloud and no Software Patents.
porter wrote: ... and N32 shared libraries should go into /usr/nekoware/lib32
+1 against - the reason we dumped that was due to o32 not being used anymore. No need to have a special n32 directory.
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
I can't see any reason to introduce /lib32 either.
jpstewart makes a few good points, and I'll add that I don't have any strong preference for share/man vs. man or share/info vs. info, just that we should agree upon one. I've been using --mandir=/usr/nekoware/man for most packages I've made in the past few years, but I don't mind switching to share/man for any future packages or updates.
In case no such thing exists yet, could someone please write a quick script that lists all files in all nekoware packages with the package name and subsystem they are contained in, like debian has in the e.g. Contents-mips.gz, separately for /current and /beta?
Back on topic regarding the release notes: If we decide to package releasenotes in /usr/relnotes, we'd need some kind of guidance what should go in there, and how it is to be structured. Those supplied by SGI look suspiciously like manpages (or catman pages, i.e. pre-rendered by roff/groff). Does anyone know which tools are used to generate them?
jpstewart makes a few good points, and I'll add that I don't have any strong preference for share/man vs. man or share/info vs. info, just that we should agree upon one. I've been using --mandir=/usr/nekoware/man for most packages I've made in the past few years, but I don't mind switching to share/man for any future packages or updates.
In case no such thing exists yet, could someone please write a quick script that lists all files in all nekoware packages with the package name and subsystem they are contained in, like debian has in the e.g. Contents-mips.gz, separately for /current and /beta?
Back on topic regarding the release notes: If we decide to package releasenotes in /usr/relnotes, we'd need some kind of guidance what should go in there, and how it is to be structured. Those supplied by SGI look suspiciously like manpages (or catman pages, i.e. pre-rendered by roff/groff). Does anyone know which tools are used to generate them?
canavan wrote: Back on topic regarding the release notes: If we decide to package releasenotes in /usr/relnotes, we'd need some kind of guidance what should go in there, and how it is to be structured.
As a user, I'd prefer that nekoware stuff stay under the /usr/nekoware tree, as it makes anything neko-related easier to find and/or troubleshoot. Maybe for release notes with important information, a link to /usr/relnotes so that they will pop up on installation ?
Packages installing components under their own umbrella (e.g. manpages under usr/nekoware/lib/xcircuit-3.82/man) should be a no-no though, imo.
In fact, I have noticed this in a few cases : what's the logic behind packages that install themselves under /usr/nekoware/lib/packagename rather than just /usr/nekoware/packagename ? They aren't really libraries, they are entire subsystems ... ?
All the relnotes files will be named like the package, so there certainly won't be any misunderstandings where they come from. My nekoware packages already spill stuff in /usr/lib/filetype/local (where they don't really belong, local probably shouldn't be touched by packages), /usr/lib/desktop/iconcatalog and /usr/lib/images, and I have to say I'd hope more packages would do the same.
The man page claims that release notes can be found in $RELNOTESPATH, but I don't think it's a good Idea to require non-standard stuff in root's environment to display "essential" information during installation.
Some time ago I thought it would be a good idea to turn the current releasnotes (i.e. the build/patch instructions) into a shell script or makefile that would automatically extract, configure, build, install and gendist the nekoware package. That would make small updates rather convenient, but requires some more standardization where sources, patches, dist files etc. need to be for the build process, and where gendist can find relnotes etc. Relative paths should be sufficient, as I'd prefer not to put unfinished stuff in /usr/nekoware while upgrading a package.
I've just tried the relnotes as Makefile Idea on neko_youtube_dl-2013.01.08.tardist (now in /incoming, I just forgot the unpacking and patching part), and while it's convenient, it doesn't really look nice. Suggestions for improvements are welcome.
The man page claims that release notes can be found in $RELNOTESPATH, but I don't think it's a good Idea to require non-standard stuff in root's environment to display "essential" information during installation.
Some time ago I thought it would be a good idea to turn the current releasnotes (i.e. the build/patch instructions) into a shell script or makefile that would automatically extract, configure, build, install and gendist the nekoware package. That would make small updates rather convenient, but requires some more standardization where sources, patches, dist files etc. need to be for the build process, and where gendist can find relnotes etc. Relative paths should be sufficient, as I'd prefer not to put unfinished stuff in /usr/nekoware while upgrading a package.
I've just tried the relnotes as Makefile Idea on neko_youtube_dl-2013.01.08.tardist (now in /incoming, I just forgot the unpacking and patching part), and while it's convenient, it doesn't really look nice. Suggestions for improvements are welcome.
Code:
make -f relnotes/neko_youtube_dl.txt PATCH BUILD PACKAGE
canavan wrote:
All the relnotes files will be named like the package, so there certainly won't be any misunderstandings where they come from.
I just like to be able to find stuff easily, so either place is fine. It's when files are spread all over the universe that life becomes hectic ... We already have a ton of /usr/nekoware/relnotes files tho, so unless it would be a big improvement I'd vote to stay with the current method.
Anyway, good to see a few of these details get sorted out so that newcomers to the pack can look in the wiki and get some guidance. Newcomers ... hello ? hello ? There must be some out there somewhere
I think is better to include as default, developers or somebody would need to check what's relevant to the packages
_________________
__Zacatito__
600 MHZ R14000; 17GBytes HD
__Nopalito__
200 MHZ R5000; 9GBytes HD
Guadalajara, Jal and Aguascalientes, Ags
Mexico