Re: Making rpm5 work with dnf

[Mark Hatle]

On 11/25/16 5:07 PM, Jeffrey Johnson wrote:
> 
>> On Nov 24, 2016, at 8:50 AM, Alexander Kanavin
>> > >
>> wrote:
>>
>> On 11/22/2016 06:10 PM, Jeffrey Johnson wrote:
>>
>>> Again: I cannot do much more than suggest porting approaches unless I can
>>> attempt reproducers.
>>> Please try to expose your git repositories somehow, either publicly or 
>>> privately.
>>
>> Here it is:
>>
>> https://github.com/kanavin/libhif/commits/master
>>
> 
> Good. I will take a look at your libhif efforts. Note that libhif is only
> one of several repositories that are going to be needed.
> 
> FWIW, your invitation expired or is otherwise unusable (but at least
> I can read your code, todo++).
> 
> (aside)
> Before we go too much further here:
> 
> What is the intent of this collaboration?

The functional goal in this work is to stop using smart in the Yocto Project and
switch to DNF.  (We've found nothing else that is a reasonable alternative that
is still under active development.)

As far as the way things are done, I'll leave that between you, Alexander and
anyone else interested.

--Mark

> You have chosen to fork libhif from
> rpm-software-management/libhif 
> 
> rather than a fork (of a fork) from
> https://github.com/rpm5/libhif
> 
> That forces our coordination to be pulled from the only common
> root at
> rpm-software-management/libhif 
> 
> which almost certainly precludes any participation from me and rpm5.org
> 
> for various reasons.
> 
> Note that there are several other efforts attempting a dnf->…->rpm5 tool chain
> that I
> am aware of. Which is why I attempted RPM5 repositories to permit 
> collaboration, and
> am perfectly willing to give write access to anyone who wishes.
> 
> I am also perfectly willing to let someone other than rpm5.org 
> 
> administrate the mess if that
> is what is desired. I do encourage all of you to collaborate early and work
> forward from
> working tools. There’s a fair amount of subtle work that will be needed imho.
> 
> What is your intent: collaboration with rpm5.org  or
> collaboration with rpm-software-management?
> 
>> I've fixed what I could by adding rpm5 includes, but the remaining build
>> issues are all caused by actual API incompatibilities between 4 and 5. I can
>> file them as separate github issues if you want.
>>
> 
> Um rpm5.org  and rpm.org  have different 
> API’s,
> and are most definitely different
> implementations these days. Its not just include files, and more than libhif 
> is
> going to
> be needed to build a working dnf->…->rpm5 tool chain.
> 
> I’ll take a look at your libhif this weekend.
> 
> 73 de Jeff
>> Alex
>>
>> __
>> RPM Package Managerhttp://rpm5.org
>> User Communication List rpm-users@rpm5.org
>> 
> 

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: RPM sqlite3 support

[Mark Hatle]

On 1/12/16 10:25 AM, Jate Sujjavanich wrote:
> I am using rpm 5.4.9 as my package manager on an embedded system, and I am
> running into some bottlenecks with the Berkeley database. I am using an SD 
> Card
> as my root file system.
> 
> The rpm transactions from a kernel upgrade take an hour or so. Using the 
> --stats
> option, I found that rpm was spending 15 or so seconds total per package in
> dbadd, dbget, etc. An strace revealed that many fsyncdata calls were 
> happening.
> It appears this is due to ACID-ity of transactions.
> 
> I found some posts saying that sqlite could be used as the database backend, 
> so
> I tried this. I tried using configure to activate sqlite without success.
> 
> I can compile with sqlite support, but so far, I can't get RPM to create any
> sqlite files. I've tried database conversion, initializing an empty RPM
> database, and setting _dbapi to 4 in /usr/lib/rpm/macros.
> 
> I discovered that within configure.ac , DBAPI is hard 
> coded
> to 3 (Berkeley DB).
> 
> I would like to know if sqlite3 as a backend is supported by RPM these days in
> 5.4.9 or any other versions. I want to find out if some of the patches within
> yocto/poky are breaking sqlite support.

sqlite3 was used semi-maintained in older versions, but by 5.4.9 it had pretty
much bit rotted to not being functional.

Note, sqlite support was -much- slower then BerkeleyDB.  It was only added to
deal with people who didn't want to have the Sleepcat license conditions.
Performance was definitely not the reason.

If your device can live w/o the syncs, you can disable them -- mostly in the RPM
configuration... just keep in mind if someone powers down in the middle of a
transaction the data base is more likely to be messed up then with the fsyncs.

--Mark

> Jate
> 

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: RPM sqlite3 support

[Mark Hatle]

On 1/12/16 2:06 PM, Tim Mooney wrote:
> In regard to: Re: RPM sqlite3 support, Jeffrey Johnson said (at 12:46pm on...:
> 
>> The sqlite3 code (and support) in rpm5 was abandoned in favor of
>> Berkeley DB ACID transactional support quite some years ago
> 
> I've been meaning to ask about this for a while, and this provides a
> good segue...
> 
> With Oracle's license change on BDB 6.x (or 12.x, or whatever they're
> calling it) to AGPL, does that impact rpm5's long-term use of BDB?

I know we and many of our commercial customers has rejected BDB 6.x because of
the change, so we've been forced to 'support' BDB 5.x.

Personally I would like to get rid of anything that has to do with BerkeleyDB,
just to get rid of this or future license questions from customers.  (But
unfortunately I don't know what can reasonably replace BDB.)

--Mark

> Tim
> 

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Which distros are using rpm5

[Mark Hatle]

On 1/15/13 11:58 AM, Sriram Narayanan wrote:

I've wanted to use rpm5 for belenix, but the other devs want to consider pacman
feeling that it's lighter.

I use rpm5 on my Dev boxes, and it's working fine for me.


OpenEmbedded/Yocto Project used RPM5.  Specifically because it gives us more 
flexibility in cross compilation and control.


--Mark


Ram

On Jan 15, 2013 2:39 PM, devzero2000 pinto.e...@gmail.com
mailto:pinto.e...@gmail.com wrote:

On Tue, Jan 15, 2013 at 9:45 AM, Ibrahim Yurtseven
arastirmaci...@aol.de mailto:arastirmaci...@aol.de wrote:
  Hey ho,
 
  Which distros are using rpm5 except Mandriva?
  Maybe Mageia, the Mandriva fork?
No. Mageia was not interested some time ago.
https://www.mageia.org/pipermail/mageia-dev/20110302/002867.html.

  Rosalab for example use rpm5 http://www.rosalab.com/. Jbj can tell you 
more.

Best
 
  --
  Ibrahim Arastirmacilar Yurtseven
  The web is what you make of it
  __
  RPM Package Manager http://rpm5.org
  User Communication List rpm-users@rpm5.org mailto:rpm-users@rpm5.org
__
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org mailto:rpm-users@rpm5.org



__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Spaces in filenames in a spec file???

[Mark Hatle]

See comments below inline..

Michael Lasevich wrote:

===
Name: vj_space_tester
Version: 1.2
Release: 090712_1925
License: None
Group: None
BuildRoot: /data/yum/factory/space_tester/root
AutoReqProv: no
Summary: No Summary
BuildArch: noarch
Requires: vj_base

# Finished header

%description

space_tester


Due to the way macros are processed, having anything that starts w/ a % in a 
comment is not guaranteed to be ignored.  If you'd like a rationale: macros are 
always expanded.. and may be multiple lines once expanded, only the first line 
would be commented out.



# Description done
#%prep
#%build
#%install
#%post


In the above remove the % or make it %%prep  (%% translates to a literal % 
and avoids expansion.)



%files
%defattr (755,root,root)
%dir 
%attr(644,root,root) /fileWithoutSpaces
%dir /dirWithoutSpaces
%attr(644,root,root) /File With Spaces
%dir /dir With Spaces
#%pre
#%preun
%changelog


I suspect the #%pre or #%preun may be part of the problem.  Remove them, or 
again change the %.


Also an empty changelog MIGHT cause problems.. (I'm not sure.)

--Mark




Relevant error output is:

Processing files: vj_space_tester-1.2-090712_1925
error: File must begin with /:
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/data/yum/factory/space_tester/root



RPM build errors:
   File must begin with /:



__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org

Re: Single RPM database, multiple platforms

[Mark Hatle]

I have attempted something similar in the past, however on the same OS. 
Different databases made it easier to manage the components.


A simple wrapper for the RPM command line items would allow you to specify 
(either automatically via uname, or manually such as --os=) and then dynamically 
switch the database.  This would be a much safer solution as well.


--Mark

Jeff Putsch wrote:

What are you trying to do?

Why not use multiple databases on different paths, which include
a platform string in the path to the rpmdb, instantly avoiding
the problem that you are seeing, instead?


Well... I need to put together a packaging system that manages multiple 
architectures (platforms) at once. The packages are installed in a 
shared disk space (NFS storage) and the directory structure being used 
needs to be backwards compatible with one already in place. We use the 
--prefix and --exec-prefix style split for most packages.


The management of the installed packages needs to happen from one or 
more computers sharing the storage and the management platforms may be 
of different OSes and architectures for a given NFS repository.


I need reporting, etc. from these hosts.

Since RPM pretty much gets the job done (the key is to get the 
RPMTAG_ARCH defined right), it seems much easier to me to have a 
single rpm database for this shared tree, than multiple trees and 
wrappers around RPM to make sure the right thing happens multiple times, 
or to take the reporting output and merge it properly (e.g. a noarch 
package installed in multiple trees should be reported only once). With 
a merged tree and RPM handling the packaging the multiple part of the 
problem takes care of itself.


Thanks, again, for clearing up what RPM keys off of! I really appreciate 
getting that straightened out.


Jeff.

--
Jeff Putsch
Email: put...@mxim.com
Office: 503.267.5480
Horse ... Water ... Drink.

__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org


__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org