rawhide report: 20050207 changes

[Build System]

Updated Packages:

beecrypt-4.1.2-1
----------------
* Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
- upgrade to 4.1.2
- put java components in sub-package.
- check that /usr/lib64 is not used on alpha (#146583).

dvgrab-1.7-1
------------
* Sun Feb 06 2005 Warren Togami <wtogami(a)redhat.com&gt; 1.7-1
- 1.7

gstreamer-plugins-0.8.7-3
-------------------------
* Sun Feb 06 2005 Warren Togami <wtogami(a)redhat.com&gt; - 0.8.7-3
- rebuild against new libraw1394

kdebase-6:3.3.2-0.3
-------------------
* Sun Feb 06 2005 Warren Togami <wtogami(a)redhat.com&gt; 6:3.3.2-0.3
- rebuild against new libraw1394

libavc1394-0.4.1-6
------------------
* Sun Feb 06 2005 Warren Togami <wtogami(a)redhat.com&gt; 0.4.1-6
- rebuild against new libraw1394

libdv-0:0.103-2
---------------
* Sun Feb 06 2005 Warren Togami <wtogami(a)redhat.com&gt; - 0:0.103-2
- Fix erroneously requiring an executable stack (Nicholas Miell #146590)

libraw1394-1.1.0-1
------------------
* Sun Feb 06 2005 Warren Togami <wtogami(a)redhat.com&gt; 1.1.0-1
- 1.1.0

libtool-1.5.12.multilib2-3.4.3
------------------------------
* Sun Feb 06 2005 Daniel Reed <djr(a)redhat.com&gt; 1.5.12.multilib2-3.4.3
- update to the 1.5.12 bugfix release
  - Makes use of $datarootdir, which is necessary for Autoconf >= 2.60.
  - Correctly skip hppa, x86_64, and s390* in tests/demo-nopic.test.
  - Interpret `include' statements in toplevel ld.so.conf file.
  - While "parsing" /etc/ld.so.conf, skip comments.
- add dependency on gcc version; /usr/bin/libtool hardcodes paths into gcc's internal
directories
- replace "libtool-libs" with "libtool-ltdl" and
"libtool-ltdl-devel"

rpm-4.4.1-0.18
--------------
* Wed Feb 02 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.4.1-0.16
- fix: length of gpg V4 hash seed was incorrect (#146896).
- add support for V4 rfc-2440 signatures.
rpmdb-fedora-1:4-0.20050207
---------------------------

beecrypt-java (Was: rawhide report: 20050207 changes)

[Anthony Green]

On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
>  beecrypt-4.1.2-1
>  ----------------
>  * Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
>  - upgrade to 4.1.2
>  - put java components in sub-package.
>  - check that /usr/lib64 is not used on alpha (#146583). 
You called this sub-package beecrypt-java.  I suggest renaming this to
something like beecrypt-java-jni.  It only contains the JNI C side of
the beecrypt java library.  The library of java code for beecrypt is
widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
beecrypt-java hasn't been packaged yet, but it will surely require this
beecrypt-java-jni.

AG

beecrypt-java (Was: rawhide report: 20050207 changes)

[Jeff Johnson]

Anthony Green wrote:

> On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
>   
>
> >beecrypt-4.1.2-1
> >----------------
> >* Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
> >- upgrade to 4.1.2
> >- put java components in sub-package.
> >- check that /usr/lib64 is not used on alpha (#146583).
> >    
> >
>
> You called this sub-package beecrypt-java.  I suggest renaming this to
> something like beecrypt-java-jni.  It only contains the JNI C side of
> the beecrypt java library.  The library of java code for beecrypt is
> widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
> beecrypt-java hasn't been packaged yet, but it will surely require this
> beecrypt-java-jni.
>   
>  
Heh, "This space reserved." is perhaps not the right approach.

Hint: A ptr to what is likely to be the best upstream source for 
beecrypt-java-2.0.0.zip
in bugzilla will fix "hasn't been packaged yet" faster than anything.

Otherwise you'll have to wait until I talk to Bob Deblier in 2 weeks or 
so ...

73 de Jeff

beecrypt-java (Was: rawhide report: 20050207 changes)

[Bob Deblier]

On Mon, 2005-02-07 at 11:45 -0500, Jeff Johnson wrote:
>  Anthony Green wrote:
>  
>  >On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
>  >  
>  >
>  >>beecrypt-4.1.2-1
>  >>----------------
>  >>* Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
>  >>- upgrade to 4.1.2
>  >>- put java components in sub-package.
>  >>- check that /usr/lib64 is not used on alpha (#146583).
>  >>    
>  >>
>  >
>  >You called this sub-package beecrypt-java.  I suggest renaming this to
>  >something like beecrypt-java-jni.  It only contains the JNI C side of
>  >the beecrypt java library.  The library of java code for beecrypt is
>  >widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
>  >beecrypt-java hasn't been packaged yet, but it will surely require this
>  >beecrypt-java-jni.
>  >  
>  >
>  
>  Heh, "This space reserved." is perhaps not the right approach.
>  
>  Hint: A ptr to what is likely to be the best upstream source for 
>  beecrypt-java-2.0.0.zip
>  in bugzilla will fix "hasn't been packaged yet" faster than anything.
>  
>  Otherwise you'll have to wait until I talk to Bob Deblier in 2 weeks or 
>  so ...
>  
>  73 de Jeff 
Jeff, Anthony,

Please ignore the old beecrypt-java-2.0.0 for now. A new version (mainly
a provider offering access to native speed algorithms, requiring the JNI
interface) is being worked on, and should start appearing in the
BeeCrypt CVS tree shortly.

Ideas and thoughts as to which direction that particular package should
evolve towards are welcome, as I get little feedback from beecrypt-java
users. Although not officially hosted there yet, any bugs or feature
requests are always welcome on the BeeCrypt SourceForge page...

Cheers,

Bob

beecrypt-java (Was: rawhide report: 20050207 changes)

[Jeff Johnson]

Bob Deblier wrote:

> On Mon, 2005-02-07 at 11:45 -0500, Jeff Johnson wrote:
>   
>
> >Anthony Green wrote:
> >
> >    
> >
> >>On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
> >> 
> >>
> >>      
> >>
> >>>beecrypt-4.1.2-1
> >>>----------------
> >>>* Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
> >>>- upgrade to 4.1.2
> >>>- put java components in sub-package.
> >>>- check that /usr/lib64 is not used on alpha (#146583).
> >>>   
> >>>
> >>>        
> >>>
> >>You called this sub-package beecrypt-java.  I suggest renaming this to
> >>something like beecrypt-java-jni.  It only contains the JNI C side of
> >>the beecrypt java library.  The library of java code for beecrypt is
> >>widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
> >>beecrypt-java hasn't been packaged yet, but it will surely require this
> >>beecrypt-java-jni.
> >> 
> >>
> >>      
> >>
> >Heh, "This space reserved." is perhaps not the right approach.
> >
> >Hint: A ptr to what is likely to be the best upstream source for 
> >beecrypt-java-2.0.0.zip
> >in bugzilla will fix "hasn't been packaged yet" faster than anything.
> >
> >Otherwise you'll have to wait until I talk to Bob Deblier in 2 weeks or 
> >so ...
> >
> >73 de Jeff
> >    
> >
>
> Jeff, Anthony,
>   
>
> Please ignore the old beecrypt-java-2.0.0 for now. A new version (mainly
> a provider offering access to native speed algorithms, requiring the JNI
> interface) is being worked on, and should start appearing in the
> BeeCrypt CVS tree shortly.
>   
>  
OK. I'll be happy to add next generation beecrypt-java to 
"beecrypt-java" whenever.

> Ideas and thoughts as to which direction that particular package
> should
> evolve towards are welcome, as I get little feedback from beecrypt-java
> users. Although not officially hosted there yet, any bugs or feature
> requests are always welcome on the BeeCrypt SourceForge page...
>   
>  
FC might be a place to get more feedback for beecrypt-java.

Anyways, see you at Cafe Subite in 2 weeks ;-)

73 de Jeff

beecrypt-java (Was: rawhide report: 20050207 changes)

[Bob Deblier]

On Tue, 2005-02-08 at 03:54 -0500, Jeff Johnson wrote:
>  OK. I'll be happy to add next generation beecrypt-java to 
>  "beecrypt-java" whenever.
>  
>  >Ideas and thoughts as to which direction that particular package should
>  >evolve towards are welcome, as I get little feedback from beecrypt-java
>  >users. Although not officially hosted there yet, any bugs or feature
>  >requests are always welcome on the BeeCrypt SourceForge page...
>  >  
>  >
>  
>  FC might be a place to get more feedback for beecrypt-java. 
That's why I'm lurking here ;)

>  Anyways, see you at Cafe Subite in 2 weeks ;-) 
Looking forward!

Cheers,

Bob

beecrypt-java (Was: rawhide report: 20050207 changes)

[Dag Wieers]

On Mon, 7 Feb 2005, Anthony Green wrote:

>  On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
>  > beecrypt-4.1.2-1
>  > ----------------
>  > * Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
>  > - upgrade to 4.1.2
>  > - put java components in sub-package.
>  > - check that /usr/lib64 is not used on alpha (#146583).
>  
>  You called this sub-package beecrypt-java.  I suggest renaming this to
>  something like beecrypt-java-jni.  It only contains the JNI C side of
>  the beecrypt java library.  The library of java code for beecrypt is
>  widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
>  beecrypt-java hasn't been packaged yet, but it will surely require this
>  beecrypt-java-jni. 
I would suggest java-something as a standard name, just like 
python-something, perl-something and other subpackage policies.

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

beecrypt-java (Was: rawhide report: 20050207 changes)

[Jeff Johnson]

Dag Wieers wrote:

> On Mon, 7 Feb 2005, Anthony Green wrote:
>
>   
>
> >On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
> >    
> >
> >>beecrypt-4.1.2-1
> >>----------------
> >>* Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
> >>- upgrade to 4.1.2
> >>- put java components in sub-package.
> >>- check that /usr/lib64 is not used on alpha (#146583).
> >>      
> >>
> >You called this sub-package beecrypt-java.  I suggest renaming this to
> >something like beecrypt-java-jni.  It only contains the JNI C side of
> >the beecrypt java library.  The library of java code for beecrypt is
> >widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
> >beecrypt-java hasn't been packaged yet, but it will surely require this
> >beecrypt-java-jni.
> >    
> >
>
> I would suggest java-something as a standard name, just like 
> python-something, perl-something and other subpackage policies.
>  
As long as beecrypt-java is a subpkg, I prefer "beecrypt-java"

OTOH, if standalone package, I would prefer "java-beecrypt", like, say, 
"python-sqlite3"
today too.

My rationale is to try to optimize the primary key retrieve on package 
file names, so
that "similar" group together when eyeballing, say, "ls -al" lists.

All is in the eye of the beholder of course, ymmv, everyone's does.

And I think "beecrypt-java-jni" waiting for a java package to magically 
appear
is rather effete, and confuses rpm package names with file names 
unnecessarily.

And no matter what, popt as subpkg of rpm confuses everyone.

But that's just me.

73 de Jeff

beecrypt-java (Was: rawhide report: 20050207 changes)

[Anthony Green]

On Mon, 2005-02-07 at 16:23 -0500, Jeff Johnson wrote:
>  And I think "beecrypt-java-jni" waiting for a java package
> to
>  magically 
>  appear
>  is rather effete, and confuses rpm package names with file names 
>  unnecessarily. 
Whatever you want to call it, the JNI library you packaged is completely
useless without the breecrypt java code.  If there's no plan to package
the java code then there's no sense in producing the JNI library.

AG

beecrypt-java (Was: rawhide report: 20050207 changes)

[Jeff Johnson]

Anthony Green wrote:

> On Mon, 2005-02-07 at 16:23 -0500, Jeff Johnson wrote:
>   
>
> >And I think "beecrypt-java-jni" waiting for a java package to
> >magically 
> >appear
> >is rather effete, and confuses rpm package names with file names 
> >unnecessarily.
> >    
> >
>
> Whatever you want to call it, the JNI library you packaged is completely
> useless without the breecrypt java code.  If there's no plan to package
> the java code then there's no sense in producing the JNI library.
>   
>  
Then there's also no reason to rename to "beecrypt-java-jni" either.

I will insure that the "beecrypt-java" package is removed tomorrow.

73 de Jeff

beecrypt-java (Was: rawhide report: 20050207 changes)

[Nicolas Mailhot]

Le lundi 07 février 2005 à 22:12 +0100, Dag Wieers a écrit :
>  On Mon, 7 Feb 2005, Anthony Green wrote:
>  
>  > On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
>  > > beecrypt-4.1.2-1
>  > > ----------------
>  > > * Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
>  > > - upgrade to 4.1.2
>  > > - put java components in sub-package.
>  > > - check that /usr/lib64 is not used on alpha (#146583).
>  > 
>  > You called this sub-package beecrypt-java.  I suggest renaming this to
>  > something like beecrypt-java-jni.  It only contains the JNI C side of
>  > the beecrypt java library.  The library of java code for beecrypt is
>  > widely known as "beecrypt-java" (google for beecrypt-java-2.0.0.zip).
>  > beecrypt-java hasn't been packaged yet, but it will surely require this
>  > beecrypt-java-jni.
>  
>  I would suggest java-something as a standard name, just like 
>  python-something, perl-something and other subpackage policies. 
Please no oh no.
Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
we have this number of java packages in jpackage.

Regards,

-- 
Nicolas Mailhot

beecrypt-java (Was: rawhide report: 20050207 changes)

[Dag Wieers]

On Mon, 7 Feb 2005, Nicolas Mailhot wrote:

>  Le lundi 07 février 2005 à 22:12 +0100, Dag Wieers a écrit :
>  > On Mon, 7 Feb 2005, Anthony Green wrote:
>  > 
>  > > On Mon, 2005-02-07 at 05:58 -0500, Build System wrote:
>  > > > beecrypt-4.1.2-1
>  > > > ----------------
>  > > > * Sat Feb 05 2005 Jeff Johnson <jbj(a)jbj.org&gt; 4.1.2-1
>  > > > - upgrade to 4.1.2
>  > > > - put java components in sub-package.
>  > > > - check that /usr/lib64 is not used on alpha (#146583).
>  > > 
>  > > You called this sub-package beecrypt-java.  I suggest renaming this to
>  > > something like beecrypt-java-jni.  It only contains the JNI C side of
>  > > the beecrypt java library.  The library of java code for beecrypt is
>  > > widely known as "beecrypt-java" (google for
> beecrypt-java-2.0.0.zip).
>  > > beecrypt-java hasn't been packaged yet, but it will surely require this
>  > > beecrypt-java-jni.
>  > 
>  > I would suggest java-something as a standard name, just like 
>  > python-something, perl-something and other subpackage policies.
>  
>  Please no oh no.
>  Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
>  we have this number of java packages in jpackage. 
Well, I'm happy that perl packages have a seperate namespace and I would 
love python, mono and java packages pursue this further than they do (even 
without a CPAN alike infrastructure).

Does Jpackage have 1000 java-class packages ? Because I'm not arguing to 
have everything java-based to fit this scheme, only packages that extend 
the java 'platform'. Just like perl-modules, python-classes or for that 
matter xmms-plugins...

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

beecrypt-java (Was: rawhide report: 20050207 changes)

[Nicolas Mailhot]

Le lundi 07 février 2005 à 23:01 +0100, Dag Wieers a écrit :

>  Well, I'm happy that perl packages have a seperate namespace and
> I would 
>  love python, mono and java packages pursue this further than they do (even 
>  without a CPAN alike infrastructure).
>  
>  Does Jpackage have 1000 java-class packages ? Because I'm not arguing to 
>  have everything java-based to fit this scheme, only packages that extend 
>  the java 'platform'. Just like perl-modules, python-classes or for that 
>  matter xmms-plugins... 
Unfortunately with java very often lib = leaf app. The jar is the lib
and with a small shell script that is often not worth spinning out in a
separate package you get you get the app.

Java is much less organised than perl or python (more accurately Java
FOSS evolved at the fringes of Sun's closed core) naming is pretty much
a mess except for some big projects like jakarta.

So you won't get an unified java namespace (unless you want jpp
packagers to lynch you;) but a classpathx namespace (for classpathx
reimplementations), a jakarta namespace, an eclipse namespace, and lots
of packages released by independant projects with no strong ties to a
big org that will probably constitute the bulk of the FOSS java
"platform" for a long time.

Unless of course someone steps ups to organise this mess and have
everyone follow some common rules. But remember the small projects chose
not to work through Sun or Jakarta/Classpath/Eclipse... so chances are
their authors are pretty independent folks.

IMHO the only entity that could do it now is Sun if it spun out Java
stewardship in a FOSS-friendly foundation but do not count on it. In the
meanwhile it'd be misleading to present Java as a perl or python-like
community when it's not. There is less communication between some of the
projects we package than say between your average Gnome and KDE
developer (which means it's not always inexistant, just uncommon).
People share Sun's langage and apis but not much anything else. Forking
is nascent because you don't have the exchanges necessary to make sure
original versions play well with everything (and people are used to get
buggy stuff from Sun it's no use to complain about - better to patch it
locally and forget about it).

On the other hand the coming of age of gcj/classpath/jakarta is very
interesting. It could provide the heart of a vibrant FOSS community with
common values and policies. But the effects won't be seen for some time
- till then the center of gravity remains Sun. Its focus on controlling
the platform makes it a cold and sterile star.

Regards,

-- 
Nicolas Mailhot

beecrypt-java (Was: rawhide report: 20050207 changes)

[Dag Wieers]

On Tue, 8 Feb 2005, Nicolas Mailhot wrote:

>  Le lundi 07 février 2005 à 23:01 +0100, Dag Wieers a écrit :
>  
>  > Well, I'm happy that perl packages have a seperate namespace and I would 
>  > love python, mono and java packages pursue this further than they do (even 
>  > without a CPAN alike infrastructure).
>  > 
>  > Does Jpackage have 1000 java-class packages ? Because I'm not arguing to 
>  > have everything java-based to fit this scheme, only packages that extend 
>  > the java 'platform'. Just like perl-modules, python-classes or for that 
>  > matter xmms-plugins...
>  
>  Unfortunately with java very often lib = leaf app. The jar is the lib
>  and with a small shell script that is often not worth spinning out in a
>  separate package you get you get the app. 
In that case the JAR is not really shared much (if at all) between other 
apps ? So in that case we would not prepend the namespace, but I 
understand it's harder with Java than perl, mono or python. It would be 
silly to have a seperate package holding just the shell-script (unless we 
want to compete with Debian in number of packages).

Still in the case of beecrypt, I would prefer java-beecrypt over 
beecrypt-java. Even if it is not a 100% cut case and the majority of the 
packages follow the exception rather than the rule. (ie. the exception is 
part of the policy too)

Thanks for the torough explanation, I picked up a few things new to me.

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

beecrypt-java (Was: rawhide report: 20050207 changes)

[Axel Thimm]

On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote:
>  Do you imagine the mess if ~ 1000 java-something hit rawhide ?
> Because
>  we have this number of java packages in jpackage. 
Regardless of naming issues, are indeed 1000 packages waiting to be
imported into rawhide? I.e. will all of jpackage be imported?

Not that I would have anything to object, but that would be a new
scaling of package imports, almost doubling the packages in rawhide
right now.
-- 
Axel.Thimm at ATrpms.net

beecrypt-java (Was: rawhide report: 20050207 changes)

[Jeff Johnson]

Axel Thimm wrote:

> On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote:
>   
>
> >Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
> >we have this number of java packages in jpackage.
> >    
> > 
I'll hazard a guess based on objective criteria:

> Regardless of naming issues, are indeed 1000 packages waiting to be
> imported into rawhide? I.e. will all of jpackage be imported?
>   
>  
Dunno all 1000 packages, but Sun's current use of rpm-3.0.4, bizarre 
shell script
extraction to add click through sufficient to satisfy legal beagles, and 
other licensing
oddities makes at least some of the jpackage packages extremely 
problematic to incorporate
into any OSS distro, not just FC.

> Not that I would have anything to object, but that would be a new
> scaling of package imports, almost doubling the packages in rawhide
> right now.
>   
>  
In case you haven't noticed, FC is showing a net loss of packages recently,
and is unlikely to suddenly decide to include all of jpackage.org.

Not that it matters, JPackage is doing a wonderful job with a messy 
problem space.

73 de Jeff

beecrypt-java (Was: rawhide report: 20050207 changes)

[Nicolas Mailhot]

Le lundi 07 février 2005 à 23:59 +0100, Axel Thimm a écrit :
>  On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote:
>  > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
>  > we have this number of java packages in jpackage.
>  
>  Regardless of naming issues, are indeed 1000 packages waiting to be
>  imported into rawhide? I.e. will all of jpackage be imported? 
I don't think so (who knows;)
But if the java-xx virus caughts on we'd have to preemptively rename a
lot of stuff just in case it gets imported someday (to avoid packagename
conflicts later)

Not fun at all;(

Regards,

-- 
Nicolas Mailhot

beecrypt-java (Was: rawhide report: 20050207 changes)

[Dag Wieers]

On Tue, 8 Feb 2005, Nicolas Mailhot wrote:

>  Le lundi 07 février 2005 à 23:59 +0100, Axel Thimm a écrit :
>  > On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote:
>  > > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
>  > > we have this number of java packages in jpackage.
>  > 
>  > Regardless of naming issues, are indeed 1000 packages waiting to be
>  > imported into rawhide? I.e. will all of jpackage be imported?
>  
>  I don't think so (who knows;)
>  But if the java-xx virus caughts on we'd have to preemptively rename a
>  lot of stuff just in case it gets imported someday (to avoid packagename
>  conflicts later)
>  
>  Not fun at all;( 
Well, that's why a policy should have been made at the very start. Naming 
is very important and the lack of a naming policy is causing all sorts of 
confusions and problems (like the lack of a 'virtual package' namespace).

And the longer we wait, the more messy it becomes the day one is 
required. Unless it is worked around by adding complexity/layers.

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

beecrypt-java (Was: rawhide report: 20050207 changes)

[Jeff Johnson]

Dag Wieers wrote:

> On Tue, 8 Feb 2005, Nicolas Mailhot wrote:
>
>   
>
> >Le lundi 07 février 2005 à 23:59 +0100, Axel Thimm a écrit :
> >    
> >
> >>On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote:
> >>      
> >>
> >>>Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
> >>>we have this number of java packages in jpackage.
> >>>        
> >>>
> >>Regardless of naming issues, are indeed 1000 packages waiting to be
> >>imported into rawhide? I.e. will all of jpackage be imported?
> >>      
> >>
> >I don't think so (who knows;)
> >But if the java-xx virus caughts on we'd have to preemptively rename a
> >lot of stuff just in case it gets imported someday (to avoid packagename
> >conflicts later)
> >
> >Not fun at all;(
> >    
> >
>
> Well, that's why a policy should have been made at the very start. Naming 
> is very important and the lack of a naming policy is causing all sorts of 
> confusions and problems (like the lack of a 'virtual package' namespace).
>
> And the longer we wait, the more messy it becomes the day one is 
> required. Unless it is worked around by adding complexity/layers.
>   
>  
FUD, plain and simple. The internet is not running out of numbers, and
lack of conventionally named packages is something that can be lived with.

rpm is already independent of package file names because SuSE had
to deal with 8.3 pakcage names.

And package names themselves have been duplicated into dependencies
for several years. All package names could be changed to whatever if
the per-package dependency name was created differently, and nothing
whatsoever would break.

User and repo maintainer confusion is a whole different matter.

73 de Jeff

beecrypt-java (Was: rawhide report: 20050207 changes)

[Nicolas Mailhot]

Le mardi 08 février 2005 à 23:39 +0100, Dag Wieers a écrit :
>  On Tue, 8 Feb 2005, Nicolas Mailhot wrote:
>  
>  > Le lundi 07 février 2005 à 23:59 +0100, Axel Thimm a écrit :
>  > > On Mon, Feb 07, 2005 at 10:34:10PM +0100, Nicolas Mailhot wrote:
>  > > > Do you imagine the mess if ~ 1000 java-something hit rawhide ? Because
>  > > > we have this number of java packages in jpackage.
>  > > 
>  > > Regardless of naming issues, are indeed 1000 packages waiting to be
>  > > imported into rawhide? I.e. will all of jpackage be imported?
>  > 
>  > I don't think so (who knows;)
>  > But if the java-xx virus caughts on we'd have to preemptively rename a
>  > lot of stuff just in case it gets imported someday (to avoid packagename
>  > conflicts later)
>  > 
>  > Not fun at all;(
>  
>  Well, that's why a policy should have been made at the very start. Naming 
>  is very important and the lack of a naming policy is causing all sorts of 
>  confusions and problems (like the lack of a 'virtual package' namespace). 
The point that you seem to miss of course is the "very start" was
several years ago for jpackage. Moreover jpackage is not a pure FC pipe
- its release schedule is not synched with FC's at all.

Even if only say 25% of the packages were to be changed they're likely
to be core packages with mass rebuilds as the result to fix requires in
the rest of the repo. For a win that's dubious at best given the
platform fragmentation.

Regards,
-- 
Nicolas Mailhot

[Ralf Ertzinger]

Hi.

Build System <buildsys(a)redhat.com&gt; wrote:

>  rpm-4.4.1-0.18 
This made my rpm go bellyside up for the root user (normal users had no problems
making queries against the database) until I manually removed all __db* files in
/var/lib/rpm. Maybe a side effect of me using smart, I don't know.

-- 
We aim to please,
we shoot to kill.

[Jeff Johnson]

Ralf Ertzinger wrote:

> Hi.
>
> Build System <buildsys(a)redhat.com&gt; wrote:
>
>   
>
> >rpm-4.4.1-0.18
> >    
> >
>
> This made my rpm go bellyside up for the root user (normal users had no problems
> making queries against the database) until I manually removed all __db* files in
> /var/lib/rpm. Maybe a side effect of me using smart, I don't know.
>   
>  
Likely to be a side effect of smart.

Upgrading through a Berkeley DB version stamp in __db* files presumes
cooperative applications, all of which are pretty deficient.

The rpm-4.4.1 package already does "best effort" to correct the problem.

However, any application that has loaded old bindings and runs another
transaction after upgrading rpm with a Berkeley DB version change,
will instanlt recreate a __db* file with the old version stamp.

That cannot be fixed in rpmlib without some insane pokery-jiggery,
it's easier to fix applications that use rpmlib imho.

I'll poke Gustavo ...

73 de Jeff