Re: please do not remove non-Release-file repos (was Re: Moo! 9th preview of APT 1.1 released: Go and test new supercow powers)
On Sat, Sep 05, 2015 at 09:21:47PM +0000, Thorsten Glaser wrote:
> Julian Andres Klode dixit:
>
> [ lots of things ]
>
> Thanks for most of that, I already thanked mvo privately for some
> of the improvements… but, I have to comment on one of the things.
> Please don’t take this eMail as negative but as “love your work,
> except, please change one tiny thing to not break peoples’ use
> cases”.
>
> >Support repositories without a release file is deprecated, and warnings will be
> >shown in such cases.
>
> I assume “deprecated” means “scheduled to be removed in a future
> version”. Please don’t do that. I use this to quickly create
> local repositories, like this:
>
> cat >/var/cache/pbuilder/result/0 <<'EOF'
> #!/bin/sh
> cd "$(dirname "$0")"
> dpkg-scanpackages . >Packages
> EOF
> chmod +x /var/cache/pbuilder/result/0
> cat >/etc/apt/sources.list.d/local.list <<'EOF'
> deb [trusted=yes] file:///var/cache/pbuilder/result ./
> EOF
Then you can also just do
apt-ftparchive release . > Release
after scanning for the Packages. That's a single line
more, I don't see why you should have a problem with
that.
>
> Then I can just hit the “0” script after a build to make the
> build result available. Being able to install .deb files from
> the command line is absolutely amazing, but for some things,
> I need them as a repo instead. (I do have a repo-creation
> script, but the above is quicker and better for development
> and unpublished stuff.)
>
> Additionally, I use it heavily in a cowbuilder hookscript:
> http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/hookdir/D00local?rev=HEAD
> As you can see, this even painstakingly avoids calling
> apt-get update (to avoid surprises at build time when
> repos that actually are external change, which may be
> undesired).
>
> The apt resolver in sbuild, and the one designed after it
> for pbuilder (yet to be merged, unfortunately; I’d prefer
> a lot to get rid of aptitude in build chroots), use this
> very same feature and construct, including copying the
> Packages file and calling only apt-cache gencaches, for
> the installation of a pseudo package containing the build
> dependencies. This can probably be done with apt install
> on the .deb, or even apt-get build-dep on the .dsc, but
> I like tools that can operate on all versions (I have
> cowbuilder chroots down to sarge).
The layout of /var/lib/apt/lists is an implementation
detail and might change without prior notice in any
release. Copying files there is not correct.
But anyway, you can just touch a Release file in there,
and things should work, in your case that's probably
a simple:
touch ${base//\//_}_._Release
which will cause APT to think your repository has
an Release file.
Or just create it and copy it over like the Packages file,
it's not a huge deal. Thats +2 lines in total if you
modify both scripts.
But a much better idea is to run apt-get update with
only the new repository added, that is:
apt-get update -o Dir::Etc::sourcelist=new repository.list \
-o APT::Get::List-Cleanup=false
apt-cache gencaches
(IIRC)
>
> So, discourage it by all means (signed repos *are* the
> way to go, after all), but don’t remove it, for those
> who do have a use case for them.
Having horrible code to support broken use case cases
is not a good idea IMO. Without a Release file APT needs
to guess which files are available and try them all until
it finds the correct ones, which is just horrible.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.
Reply to: