[OE-core] [PATCH RFC] Support hierarchical ipk feeds

[Paul Barker]

On Thu, May 08, 2014 at 11:03:05PM +0100, Richard Purdie wrote:
> On Thu, 2014-05-08 at 16:55 +0000, Paul Barker wrote:
> > This is an RFC only and is not suitable for merging yet. The necessary patches
> > for opkg-utils have also been posted for review but have not been merged yet. I
> > want to know if there is general approval for adding this feature to oe-core. If
> > there is, I'll go ahead and merge the opkg-utils patches and post a new patch
> > series which includes the update to the SRCREV used for opkg-utils in oe-core.
> > 
> > This patch has been tested on qemuarm:
> > 
> >   A feed was created with IPK_HIERARCHICAL_FEED unset and opkg was pointed at
> >   that feed. 'opkg update && opkg install ncurses-terminfo-base' worked
> >   correctly, downloading a package file from the same directory as the package
> >   feed.
> >   
> >   IPK_HIERARCHICAL_FEED was then set to "1" in local.conf and the feed was
> >   rebuilt by running 'bitbake core-image-minimal && bitbake package-index'. On
> >   qemu 'opkg update && opkg install ncurses-terminfo' worked correctly,
> >   downloading the package from the subdirectory 'n/ncurses-terminfo'.
> > 
> >   Finally, IPK_HIERARCHICAL_FEED was unset again and the feed was rebuilt. On
> >   qemu 'opkg update && opkg install ncurses' worked correctly, downloading
> >   package files from the same directory as the package feed again.
> > 
> > Those tests prove that changes to IPK_HIERARCHICAL_FEED do not break the upgrade
> > path of an existing system provided that 'bitbake pacakge-index' is re-ran after
> > the change.
> > 
> > The proposed commit message follows...
> > 
> > 
> > 
> > package_ipk.bbclass: Support hierarchical feed
> > 
> > This patch allows for an optional new layout for ipk feed directories which I've
> > called a 'hierarchical feed' and is based on how Debian pools package files. It
> > is disabled by default and is enabled by setting IPK_HIERARCHICAL_FEED to "1".
> > 
> > In the traditional feed layout, package files are placed in <outdir>/<arch>/.
> > This can lead to several thousand files existing in a single directory which is
> > often a problem if developers want to upload a package feed to a shared web
> > hosting provider. For example, in my case, listing files via FTP only shows the
> > first 2000 files, breaking my scripts which attempt to upload only new and
> > changed files via FTP.
> > 
> > In the hierarchical feed, package files are written to
> > '<outdir>/<arch>/<pkg_prefix>/<pkg_subdir>', where pkg_prefix is the first
> > letter of the package file name for non-lib packages or "lib" plus the 4th
> > letter of the pacakge file name for lib pacakges (eg, 'l' for less, 'libc' for
> > libc6).  pkg_subdir is the root of the pacakge file name, discarding the version
> > and architecture parts and the common suffixes '-dbg', '-dev', '-doc',
> > '-staticdev' and '-locale-*'.
> > 
> > This change relies on recent patches to opkg-utils which support hierarchical
> > package feeds.
> 
> FWIW I'm ok with this and its something we probably want to enable by
> default however:
> 
> a) I'm not sure <pkg_subdir> is that useful, we tend to only have one
> version of things around in most cases and I can't imagine people having
> a lot of these.

pkg_subdir does reduce the number of files in a single directory quite a bit,
especially when several locale-specific packages are created.

Also, one of the features I'm currently working on in opkg is per-package
signatures. These would be separate '.sig' or '.asc' files next to each package
file so that will immediately double the number of files per directory if it is
used.

I do keep an archive of old packages around so that if something breaks I can
just tell people to revert back to the old version.

There is one thing slightly specific to my use case and that is that the number
of directories in each directory doesn't matter but the number of files in each
directory does matter. This is because the mirror operation will do a separate
'ls' for each subdirectory (cheap) whether or not it saw it in the 'ls' of the
parent directory, however it will do a full upload (expensive) for each file it
didn't see in the 'ls'. Thus every file past number 2000 is uploaded in full
even if it was already on the server. Fixing this would require patching lftp
which I haven't had time to look at yet.

> 
> b) How are the "common suffixes" configured? I guess its just a loose
> thing but I worry about the "why did my package get put into directory X
> when its really part of Y?" type questions. Perhaps splitting on the
> first dash in the name might be good enough? I'm thinking about
> kernel-modules-xxx for example and some of our other dynamically
> generated packages.
> 

The common suffixes are just my best guess at the minute. They certainly don't
group all related packages together. They just handle the suffixes that are
automatically packaged ('-dev', '-dbg', etc), plus locales. I've not even looked
through the packaging code to see if I've got the full list of automatic
suffixes - I'll do that before this is merged.

Splitting on the first dash could be confusing for packages which have a dash in
their 'well known' name (eg. util-linux, update-rc.d, etc).

'kernel-modules-xxx' looks good at first glance but it would immediately end up
with many many packages in one directory.

> Cheers,
> 
> Richard
> 
> 

Thanks,

-- 
Paul Barker

Email: paul at paulbarker.me.uk
http://www.paulbarker.me.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140508/7ec9ea32/attachment-0002.sig>