Issue with the pkgng repository

2012-12-04 Thread Walter Hurry
I have another minor issue with pkgng:

Say package foo-1.0 depends on bar-1.0. Then bar-1.0 is upgraded to 
version 1.1.

So a new package bar-1.1 is built (from the port), and replaces bar-1.0 
in the repository. The repository database is then updated using 'pkg 
repo'. 

Now the repository database is out of whack: It still thinks foo-1.0 
depends on bar-1.0 (the deps table in the compressed repo.sqlite database 
- i.e. repo.txz in the repository).

Admittedly the packages will still install (from the repository in 
question) on another machine, but nevertheless it doesn't seem quite 
right.

One workaround is to re-create the foo package (plus any others depending 
on bar) and refresh the repository, but is this an omission?

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Issue with the pkgng repository

2012-12-04 Thread Matthew Seaman
On 04/12/2012 20:52, Walter Hurry wrote:
 I have another minor issue with pkgng:
 
 Say package foo-1.0 depends on bar-1.0. Then bar-1.0 is upgraded to 
 version 1.1.
 
 So a new package bar-1.1 is built (from the port), and replaces bar-1.0 
 in the repository. The repository database is then updated using 'pkg 
 repo'. 
 
 Now the repository database is out of whack: It still thinks foo-1.0 
 depends on bar-1.0 (the deps table in the compressed repo.sqlite database 
 - i.e. repo.txz in the repository).
 
 Admittedly the packages will still install (from the repository in 
 question) on another machine, but nevertheless it doesn't seem quite 
 right.
 
 One workaround is to re-create the foo package (plus any others depending 
 on bar) and refresh the repository, but is this an omission?

This is a flaw in your package repository maintenance process.  If
bar-1.0 is upgraded to bar-1.1 then you should rebuild all the packages
that have a direct dependency on it, and possibly many of the packages
that have an indirect dependency too.  I say 'rebuild' because that is
generally what happens in practice, even though in many cases you could
probably get away with simply repackaging everything that requires bar-1.x.

Not always though, and it's hard to tell the difference programatically
in the general case.  If, for example, bar-1.0 provides libbar.so.1 and
bar-1.1 provides libbar.so.2 then full rebuilds are definitely required
for anything that ultimately links against libbar.so.  And to discover
that 100% accurately, you have to examine the dynamic linkage
characteristics of every ELF file in every package with bar-1.x
somewhere in its dependency tree.  (No, LIB_DEPENDS cannot be relied on
for this) That's just once example reason why you might need a full
rebuild.  There are many more.  Which is why it is standard to just punt
and rebuild everything that requires bar-1.x.

Tracking this sort of stuff manually is pretty tedious.  Which is why
things like poudriere and tinderbox exist; so you can automate.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk



signature.asc
Description: OpenPGP digital signature


Re: Issue with the pkgng repository

2012-12-04 Thread Walter Hurry
On Tue, 04 Dec 2012 21:32:19 +, Matthew Seaman wrote:

 This is a flaw in your package repository maintenance process.

Helpful and detailed response snipped for brevity

Thanks. Noted. I shall rethink the process accordingly.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org