[pacman-dev] [PATCH 04/13] libalpm: handle both .db and .files extensions
allan at archlinux.org
Wed Jun 24 01:55:37 UTC 2015
On 24/06/15 11:24, Andrew Gregory wrote:
> On 06/24/15 at 09:08am, Allan McRae wrote:
>> On 24/06/15 02:04, Andrew Gregory wrote:
>>> On 06/23/15 at 11:03pm, Allan McRae wrote:
>>>> On 20/06/15 23:29, Andrew Gregory wrote:
>>>>> On 06/20/15 at 05:42pm, Allan McRae wrote:
>>>>>> Reads from the .db or .files database depending on the flags in the handle.
>>>>>> Signed-off-by: Allan McRae <allan at archlinux.org>
>>>>>> lib/libalpm/be_sync.c | 23 +++++++++++++++++------
>>>>>> lib/libalpm/db.c | 10 ++++++++--
>>>>>> 2 files changed, 25 insertions(+), 8 deletions(-)
>>> The point I was trying to make, and clearly did a poor job of, is just
>>> that I generally prefer to keep logic in the front-end wherever that
>>> can be easily done. The less we hard-code in the back-end, the more
>>> flexibility front-ends have. What I envision in this case is to allow
>>> front-ends to specify the db extension. So front-ends would simply
>>> call something like `alpm_option_set_syncdb_extension(".files")`
>>> instead of `alpm_option_set_dbtype`. libalpm would then simply load
>>> the sync databases normally using whatever extension was specified and
>>> load the files data if the db happens to include it.
>>> I'm not sure how you intend to implement the source db's, so having
>>> front-ends set the extension may not make sense in light of that.
>> It will be a db ending in .source, and probably require a be_source to
>> parse it given the architecture specific depends etc.
> Will the source db's just be normal sync db's with additional
> information for building from source or do you intend them to be
> something different altogether? If they're just sync db's with extra
> source information it could still be conditionally loaded when present
> the same way file information is even if it does require more complex
For source repos, I just want to get it to the ABS replacement stage.
pacman -B glibc would download an extract glibc-x.xx.src.tar.gz and dump
it in /var/build (configurable). Then the user would run makepkg.
> If they aren't going to have the standard sync db information, I'm
> curious what alpm will do when syncing a package from a source db.
I suppose having separate source repos for every architecture would mean
no architecture specific fields... and be_sync could be used. Hrm...
But still handling a source package will be very different than a
> Once a front-end selects source db's will it be an all-or-nothing
> situation where only source packages can be used, including any
> dependencies that get brought in?
This is currently the case. You register the sync db with
alpm_register_syncdb. To change between dbs we need to unregister the
db and register a new one.
>> When that happens, the extensions will have meaning. We will not be
>> able to just throw a db at makepkg and parse it as if it is a sync db.
> If we are going to give the db extension real meaning, then I agree
> that having front-ends just select the type and letting libalpm figure
> out the extension is the way to go.
>> What I am not understanding is why there is a need for the frontend to
>> be able to set the extension rather than the type? I am all for
>> flexibility when there is a defined need. In this case, repo-add only
>> creates db with the ".db" extension - with the equivilant .files db made
>> at the same time.
> Part of the point of providing extra flexibility where we can is so
> that front-ends can handle situations that we don't think of. I'm
> only suggesting this alternative because, as it stands now, this seems
> to me like a case where we can provide that extra flexibility at
> *zero* cost to either the back-end or front-end implementations. If
> it's going to complicate future development though, it's not worth it.
There is cost due to alpm_register_syncdb(). I suppose that changing
the extension could release the syncdbs and laod the new one.
> Also keep in mind that just because repo-add is the officially
> provided tool for managing repositories doesn't mean it's the only
The filenaming is documented in the repo-add man page. If other tools
are not following the example of repo-add, they are doing it wrong...
> There is another problem that stems from the selection being global,
> but would be somewhat alleviated by allowing file information to be
> parsed from normal .db files. As it stands now front-ends cannot load
> file information for repos that have it while falling back to
> a standard db otherwise. This would be particularly hard on GUI
> front-ends which would have to switch back and forth between normal
> and file db's in order to provide file information to users while
> still allowing the use of the repos lacking a files db.
repo-add now unconditionally creates the .files db. So all repos should
provide it (assumption I know...). I should check what happens if a
repo does not provide the .files db...
I am more than happy to make adjustments to the alpm backend to help GUI
developers, but I would require actual GUI developers to post here with
what they need. I am not programming for a potential need, when there
are actual needs going unaddressed. If you happen to be writing a GUI,
then there is a need!
More information about the pacman-dev