[bug-notifications] [pkg_get 0000673]: pkg-get doesnt cope with pkgask files yet

Mantis Bug Tracker noreply at opencsw.org
Sun Mar 1 03:12:58 CET 2009


A NOTE has been added to this issue. 
====================================================================== 
http://opencsw.org/mantis/view.php?id=673 
====================================================================== 
Reported By:                duncs
Assigned To:                phil
====================================================================== 
Project:                    pkg_get
Issue ID:                   673
Category:                   other
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     resolved
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2004-10-19 09:18 CEST
Last Modified:              2009-03-01 03:12 CET
====================================================================== 
Summary:                    pkg-get doesnt cope with pkgask files yet
Description: 
pkg-get doesnt know how to use pkgask files. (i.e. pkgadd -r <pkgask>
<pkg>).  Patch provided in \"additional information\". 
Note: the patch requires the catalog file to include $6 as
\"pkgask\" and will be used for a package name call
<pkg>.pkgask[.gz] (whereas package is <pkg>.pkg[.gz]).  Patch
is against pkg-get version \"pkg-get SCCS rev 2.45\".  Why do i
need this?  I use pkg-get against my own internal repository for
distributing packages around a few hundred machines.  A few of those
packages need pkgask files to install correctly.  Note also in my own
package i drop in a verion of wget into /var/pkg-get/ to ensure there is
always one available if it hasnt otherwise been installed on the machine.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0000679 Even with  pkg-get -f  requires interac...
====================================================================== 

---------------------------------------------------------------------- 
 (0001201) phil (manager) - 2004-10-19 14:38
 http://opencsw.org/mantis/view.php?id=673#c1201 
---------------------------------------------------------------------- 
rather than just dumping a hundred or so lines of patch on me, how about
describing from the user\'s point of view how your proposal would work.
I dont see how this would work in a clean fashion, from a user\'s
perspective. 

---------------------------------------------------------------------- 
 (0001202) phil (manager) - 2004-10-19 14:39
 http://opencsw.org/mantis/view.php?id=673#c1202 
---------------------------------------------------------------------- 
PS: putting wget in /var/pkg-get seems like a non-optimal method of doing
things. It can be anywhere in the PATH, so you should either just copy it
over to somewhere in your standard PATH, or extend your PATH to somewhere
temporary, rather than hacking up the pkg-get script. 

---------------------------------------------------------------------- 
 (0001205) duncs (reporter) - 2004-10-20 05:27
 http://opencsw.org/mantis/view.php?id=673#c1205 
---------------------------------------------------------------------- 
re: the patch - sorry \'bout that but couldnt see any way of uploading it
as a file instead (maybe add an \"upload patch\" option on the
web page?)

Basically, for those people that use pkg-get with their own repository
(and maybe for some CSW packages too) the repository admin drops in the
pkgask file in the same place as the package, but called <pkg>.pkgask
instead of <pkg>.pkg.  In the \"pkg-get -c\" output a 4th
column is added that should state whether or not a package ask file exists
)\"pkgask\" in column 6 of the catalog file).  The user can then
decide whether or not to use it for installing the package by using
\"pkg-get -p -i <pkg>\".  Why?  To totally automate
installation of all packges for 100% hands-off installs (i.e. for SUNWexplo
4.2 and 4.2.1 - i think 4.3 is differnt now).  We have 400+ solaris servers
and we have always had a nightmare of a time trying to keep up to date on
packages.

edited on: 10-20 02:27 

---------------------------------------------------------------------- 
 (0001206) duncs (reporter) - 2004-10-20 05:28
 http://opencsw.org/mantis/view.php?id=673#c1206 
---------------------------------------------------------------------- 
re: wget - i have stuck the pkg-get package into our jumpstart system, and
this seemed the easiest way of ensuring there was a bog-standard wget
install (that could be superceeded by installing a more up-to-date package
- /var/pkg-get is last in the PATH).  This way it should always work by
only having to install 1 package instead of 2 or more to get pkg-get
working.

One problem I have (working in a financial institution) is our security
team do not want extra (\"unnecessary\") packages installed where
it can be avoided and this was one of their rules.

BTW - i am also working on a possible solution to the dependency version
checking for I, P and R (if you are interested in having it and when i
prove it works...)

edited on: 10-20 02:28 

---------------------------------------------------------------------- 
 (0001208) phil (manager) - 2004-10-20 13:57
 http://opencsw.org/mantis/view.php?id=673#c1208 
---------------------------------------------------------------------- 
Having to modify the catalog file seems like an extreme and unneccessary
task.
Particularly if you plan to have per-package unique pkgadd files.
How about a nice simple standard /var/pkg-get/pkgask/CSWxxxxx   ?
pkg-get could then check for the existance of a pkgadd file for a
package,
directly before it pkgadds it.

My ownly reservation about this would be whether to go by PKGname, or
software name. Perhaps I should check for both.
But in that case, I still need to decide on which would take priority if
both are present. 

---------------------------------------------------------------------- 
 (0001221) duncs (reporter) - 2004-10-25 09:46
 http://opencsw.org/mantis/view.php?id=673#c1221 
---------------------------------------------------------------------- 
I dont fully understand what you mean by the pkgask files being in
/var/pkg-get/pkgask - however, if the repository contains a pkgask file
without the catalog being modified, pkg-get will need to check for the
pkgask for every package every time you run -U which to me seems a very
\"expensive\" way of doing things, and modifying the
catalog/description generator is a trivial task.  

As for the software name - i wouldnt worry about that bit - pkgask files
are specific to packages (and version of packages in most cases).  In my
mind the pkgask file should always match the package name, otherwise it can
all get too confusing. 

---------------------------------------------------------------------- 
 (0001222) phil (manager) - 2004-10-25 11:35
 http://opencsw.org/mantis/view.php?id=673#c1222 
---------------------------------------------------------------------- 
pkgadd files in the *repository*? nono. pkgadd files must be site-local.
you make your own. you would put them in /var/pkg-get/pkgask yourself. 

---------------------------------------------------------------------- 
 (0001223) duncs (reporter) - 2004-10-25 11:44
 http://opencsw.org/mantis/view.php?id=673#c1223 
---------------------------------------------------------------------- 
This is the whole point of me running my own internal repository, so i
don\'t have to locally admin any of my 400+ servers for such things.  I
guess i\'ll have to keep patching my own local copy for any new versions
then.  Oh well. 

---------------------------------------------------------------------- 
 (0005595) phil (manager) - 2009-03-01 03:08
 http://opencsw.org/mantis/view.php?id=673#c5595 
---------------------------------------------------------------------- 
it's been a long time coming, i'm afraid... but i finally am having a
"patch the heck out of pkg-get" day again :) and this bug has hit the top
of the remaining list.

I have implemented some code changes, so that pkg-get 4.x will now check
for BOTH a local pkgask file, and ALSO a GLOBAL pkg-ask file.
Going with our assumption that /opt/csw is globally shared, the global
config is looked for in /opt/csw/etc/pkgask/

even if you dont currently nfs-share out /opt/csw, you could then choose
to at least globally share /opt/csw/etc/pkgask.
hope this meets your needs. 

---------------------------------------------------------------------- 
 (0005596) phil (manager) - 2009-03-01 03:10
 http://opencsw.org/mantis/view.php?id=673#c5596 
---------------------------------------------------------------------- 
PS: it hasnt quite yet been released :) but expect pkg-get 4.1 to be
released to testing this weekend.

http://mirror.opencsw.org/testing.html 

---------------------------------------------------------------------- 
 (0005597) phil (manager) - 2009-03-01 03:12
 http://opencsw.org/mantis/view.php?id=673#c5597 
---------------------------------------------------------------------- 
Hmm. in retrospect, it doesnt quite make sense to have a globally shared
/opt/csw, if you are adding packages locally. but at least the location is
consistent; If you want global configurations, you can share out
/opt/csw/etc.
Or config/replicate it with puppet or something, as you require.
That way, it can stay nice and automated, and globally consistant, one way
or another. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-01 03:08 phil           Note Added: 0005595                          
2009-03-01 03:09 phil           Status                   assigned => resolved
2009-03-01 03:09 phil           Resolution               open => fixed       
2009-03-01 03:10 phil           Note Added: 0005596                          
2009-03-01 03:12 phil           Note Added: 0005597                          
======================================================================




More information about the bug-notifications mailing list