pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread sebastian . rother
Hello everybody,

Tec-Note: OpenBSD-3.9 STABLE on amd64

The -ui Switch for pkg_add is a realy wonderfull development but it
needs updated Packages at the FTP.

Just some examples from Software updated using Ports:
Candidates for updating clamav-0.88.2 - clamav-0.88
Candidates for updating cups-1.1.23p8 - cups-1.1.23p8 - ?
Candidates for updating curl-7.15.3 - curl-7.15.1

Would it maybe possible to add a use the damn ports-Switch to pkg_add?
So that it uses the Ports except of the Packages (Somethign like -uip).

Why?

1. Ports are mostly more up2date then the Packages
   - Efficent and less work for the Maintainer
2. Peoples who wanna update don`t have to wait until somebody build a
   package
   - I mean such neat automatic-update (pkg_add -ui)
   - Creating Packages needs time (many Archs...)
3. Maybe even less traffic for the main-FTP
   - CVS-Updates should be made anyway

As I already wrote in another mail.
For now pkg_add -ui is kind of useless to keep a System up2date.
It`s more like a upgrade-Tool if you switch from 3.8 to 3.9 or from 3.9
to current. But it`s not helping to keep the 3rd-Party-Software updated so
nearly any Admin (well imagine somebody has Workstations with OpenBSD ;-)
) has to use the Ports anyway.

That`s just my idea how to (maybe..?) solve that problem.
And the problem is not a technical one... it`s more the time needed for
somebody (don`t know who it is) to create the Packages.
And if this guy simply has no time (well he spends his spare-time I guess)
there`s no update and so using Ports is the only way anyway.

Kind regards,
Sebastian



Re: pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread Stuart Henderson
On 2006/06/19 13:55, [EMAIL PROTECTED] wrote:
 Tec-Note: OpenBSD-3.9 STABLE on amd64
 
 The -ui Switch for pkg_add is a realy wonderfull development but it
 needs updated Packages at the FTP.
 
 Just some examples from Software updated using Ports:
 Candidates for updating clamav-0.88.2 - clamav-0.88
 Candidates for updating cups-1.1.23p8 - cups-1.1.23p8 - ?
 Candidates for updating curl-7.15.3 - curl-7.15.1
 
 Would it maybe possible to add a use the damn ports-Switch to pkg_add?
 So that it uses the Ports except of the Packages (Somethign like -uip).

You can do this the other way round, and make ports use packages
where possible; see FETCH_PACKAGES in bsd.port.mk(5).

 For now pkg_add -ui is kind of useless to keep a System up2date.

If you want a really up-to-date system, you can always run
-current, the snapshot packages are built quite often and by
doing this and providing good reports of problems you'll
help make the next version better.

Or if you have enough systems using the same arch for it
to be worthwhile, you can build your own packages and point
PKG_PATH there.



Re: pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread sebastian . rother
 On 2006/06/19 13:55, [EMAIL PROTECTED] wrote:
 Tec-Note: OpenBSD-3.9 STABLE on amd64

 The -ui Switch for pkg_add is a realy wonderfull development but it
 needs updated Packages at the FTP.

 Just some examples from Software updated using Ports:
 Candidates for updating clamav-0.88.2 - clamav-0.88
 Candidates for updating cups-1.1.23p8 - cups-1.1.23p8 - ?
 Candidates for updating curl-7.15.3 - curl-7.15.1

 Would it maybe possible to add a use the damn ports-Switch to pkg_add?
 So that it uses the Ports except of the Packages (Somethign like -uip).

 You can do this the other way round, and make ports use packages
 where possible; see FETCH_PACKAGES in bsd.port.mk(5).

Bad idea because the packages at $ANY_OFFICIAL_FTP are not updated.

 For now pkg_add -ui is kind of useless to keep a System up2date.

 If you want a really up-to-date system, you can always run
 -current, the snapshot packages are built quite often and by
 doing this and providing good reports of problems you'll
 help make the next version better.

That`s not what I ment as I said up2date. up2date for stables means all
Patches avaiable for stable.
So if you use Stable but curl *.1 except of *.3 you`re not up2date. :)
That`s how I ment it.

 Or if you have enough systems using the same arch for it
 to be worthwhile, you can build your own packages and point
 PKG_PATH there.

Well at home 1 AMD64 and 3 i386 (even just 2 of 3 use OpenBSD).
I just wanted to point out that with pkg_add -ui there`s a VERY GOOD
solution but even the best solution is useless if the packages don`t get
updated.
Maybe that can get solved with a Script *looks to the dev-Team* to update
the packages on the FTP if a update is avaiable via Ports.

Or, the other solution, would be enable pkg_add -ui (maybe with another
argument to use Ports) using the Port-system to update.

It`s not so easy to update all machines using the ports
Easy == like pkg_add -ui :-/

That`s all I wanted to point out. Why not using this neat update-tool
(pkg_add -ui) because for now the dev-team limits it to a upgrade-tool
(from one release to another) except an update-tool. And that`s kind of
sad in my oppinion.

Kind regards,
Sebastian
-- 
Don't buy anything from YeongYang.
Their Computercases are expensiv, they WTX-powersuplies start burning and
their support refuse any RMA even there's still some warenty.



Re: pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread Seth Hanford
 It`s not so easy to update all machines using the ports
 Easy == like pkg_add -ui :-/

I love the OpenBSD package/ports system. 3 developments that I
discovered recently:

1. pkg_add -ui, but it has deficiencies (such as no -stable packages for
sparc64)
2. /usr/ports/infrastructure/build/out-of-date -- this tells you what
needs updated
3. make update in ports -- this builds the new package, does pkg_add -r
on the old one, and puts the new one in place. seamless, awesome.

So get a ports tree on a fast system with disk (relatively speaking; i
use a duron 700 instead of trying to build on my mini-itx firewall with
only 512MB CF). Update the ports tree to stable, then run out-of-date.
Out-of-date tells you what ports need updated, so either pkg_add -ui or
run make update on unsupported-by-stable-packages-archs or if you need
it faster than what shows up on the i386 FTP.

If you have multiple systems of the same arch, you can make package
and then distribute to your own systems via FTP/HTTP/etc.

I do this on my sparcs -- make package on one, then use the pkg_add to
install on it and the rest.

I have no complaints about the package/ports updating system. This is
light years ahead of where it was even 2 releases ago (or is it 3?).
Marc Espie  all involved are my heroes. In general, I think a lot of
people would be better served to watch the commit mailers or general
announcements like plus.html and read documentation instead of
complaining about how bad things are. Note this isn't a personal attack
on you, sebastian, just an observation in general. Package management
has come a long way, and I hope more people realize it and be thankful.

- Seth

 That`s all I wanted to point out. Why not using this neat update-tool
 (pkg_add -ui) because for now the dev-team limits it to a upgrade-tool
 (from one release to another) except an update-tool. And that`s kind of
 sad in my oppinion.
 
 Kind regards,
 Sebastian



Re: pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread Will Maier
Sebastian: you screwed up the attributions. That makes things (more)
confusing. Fix your MUA.

On Mon, Jun 19, 2006 at 05:10:21PM +0200, [EMAIL PROTECTED] wrote:
  You can do this the other way round, and make ports use packages
  where possible; see FETCH_PACKAGES in bsd.port.mk(5).
 
 Bad idea because the packages at $ANY_OFFICIAL_FTP are not
 updated.

Yes, they are. Packages are built for stable, too, if security
updates are backported to the stable ports tree. What's the problem
here?

 That`s not what I ment as I said up2date. up2date for stables
 means all Patches avaiable for stable. So if you use Stable but
 curl *.1 except of *.3 you`re not up2date. :) That`s how I ment
 it.

What? I have no clue what you meant by this. Updated packages are
bulit for stable when updates are backported. Period. Look at the
updates[0] available for 3.9-stable. What's the problem here?

  Or if you have enough systems using the same arch for it to be
  worthwhile, you can build your own packages and point PKG_PATH
  there.
 
 Well at home 1 AMD64 and 3 i386 (even just 2 of 3 use OpenBSD). I
 just wanted to point out that with pkg_add -ui there`s a VERY GOOD
 solution but even the best solution is useless if the packages
 don`t get updated. Maybe that can get solved with a Script *looks
 to the dev-Team* to update the packages on the FTP if a update is
 avaiable via Ports.

This happens already[0].

 Or, the other solution, would be enable pkg_add -ui (maybe with
 another argument to use Ports) using the Port-system to update.

 It`s not so easy to update all machines using the ports Easy
 == like pkg_add -ui :-/

So, assuming there's no package available, just make the package
(ports(7)) and install it on other machines with the same arch (like
Stuart suggested). Or add your build machine to your other machines'
PKG_PATH. It's easy.

But chances are, there's an updated package available. Don't expect
new features if you're running -stable.

 That`s all I wanted to point out. Why not using this neat
 update-tool (pkg_add -ui) because for now the dev-team limits it
 to a upgrade-tool (from one release to another) except an
 update-tool. And that`s kind of sad in my oppinion.

Again, this is unclear. But pkg_add handles upgrades _and_ updates.
If you're running -stable, you might not notice many package
updates, since that'll only happen when a new package is built to
address a security problem. If you want more packages to be built
faster, submit diffs to update the ports you're concerned with,
donate resources for a larger build infrastructure, or build your
own packages.

[0]http://www.openbsd.org/pkg-stable.html

-- 

o--{ Will Maier }--o
| jabber:[EMAIL PROTECTED] | [EMAIL PROTECTED] |
| freenode:..lt_kije | freenode:#madlug,#wilug |
*--[ BSD Unix: Live Free or Die ]--*



Re: pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread steven mestdagh
Will Maier [2006-06-19, 11:04:00]:
 Yes, they are. Packages are built for stable, too, if security
 updates are backported to the stable ports tree. What's the problem
 here?

note that due to lack of resources, updated -stable packages are only
built for the i386 platform.

you can build your own packages from a -stable ports tree, though.
the out-of-date script will even give you a list that you can feed into
the ports Makefile...

-- 
steven

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



Re: pkg_add -ui - Using Ports except or real Packages?

2006-06-19 Thread Marc Espie
On Mon, Jun 19, 2006 at 05:10:21PM +0200, [EMAIL PROTECTED] wrote:
 Or, the other solution, would be enable pkg_add -ui (maybe with another
 argument to use Ports) using the Port-system to update.

The interface will use PKG_PATH. After all, using ports is just another
kind of url, similar to ftp/scp.

Unfortunately, this needs an almost complete rewrite/redesign of the
way package lookups and package repositories are handled in the current
tools.

If you want, you can look at what's going on yourself, look in the package
tools, around the PackageLocator.pm file and the PackageRepository stuff.
You'll notice finding packages is not as generic as it should be (there
should be a generic `search object', so that you can locate packages by stem,
or by package path, or some other combinations), and the current way to
look up packages does things the wrong way (looks in every repository instead
of stopping at the first one that holds reasonable candidates)... and there's
even some completely non-functional scaffolding to go build packages from
the ports tree.

Hey, if it was 4 hours of work, it would already be in the ports tree.

The other way around (FETCH_PACKAGES) has been functional since the last
ports hackathon thanks to nikolay, and there were already quite a few
minor issues to solve to make it work correctly (partial downloads did tend
to stick around in the package cache).

As far as building and replacing in source goes, we do know we actually need
to replace libtool with something that works, and doesn't go looking in
/usr/local all the time (obnoxious twit), but again, this is  not a 4 hours
endeavor...