Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Goswin von Brederlow writes ("Re: Atlas proposal"):
>> I also have a package "local-archive" that depends on reprepro,
>> generates a local signing key on first install, adds that to the apt-get
>> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
>
> I think this scheme is a very bad idea. I don't think packages should
> be recursing into the packaging infrastructure this way. And I think
> automatically adding different local repositories to the apt
> configuration is pretty horrid.
Calling 'dpkg -i' from postinst is impossible due to the locks against
recursion.
Going into background, waiting for dpkg/apt to finish and then calling
dpkg -i is horrible. I often do upgrades in multiple apt calls and then
either my or atlases dpkg -i call would suddenly fail with a lock error.
Unacceptable.
Just dumping the compiled files into /usr/lib/ I find quite unacceptable
too.
So what is left then? Build a deb and tell the admin to dpkg -i it
manually? That is quite horrible on upgrades since you then potentially
need to apt-get -f install to fix the depends and reverse depends. Imho
also unacceptable.
What I described is simple to implement, easy to use and debug and verry
comfortable for the user. The users prefered frontend
(dselect/apt/aptitude/synaptic/adpet/...) will sort out the upgrade to
the new version cleanly and no special invocations of some update script
or manual dpkg calls are required.
The only ugly part I see is dumping a file in /etc/apt/sources.list.d/
and adding the gpg key. You could ask the admin to do that manually but
I found it easier to have it done automatically for me.
>> Using a local archive instead of calling dpkg -i directly avoids the
>> locking issues. It also allows exporting the archive for a pool of
>> systems. No need to build libatlas3gf 200 times for a 200 node cluster.
>
> The build time problem is easily solved by the cluster admin using a
> ccache, if indeed we care.
>
> Having said that:
>
> Josselin Mouette writes ("Re: Atlas proposal"):
>> I beg any FTP master reading this to immediately reject any package
>> doing something as sick as what you just described.
>
> I don't think this is a very friendly way of putting it. Invoking or
> mentioning escalation is not necessary in what was previously a
> reasonable and technical discussion.
>
> If you dislike Goswin's idea so much you should set out your
> criticisms of it.
>
> Ian.
Esspecially you should say WHY you think it is bad. How else will I
learn anything? It is like proofreading someones book and then only
saying: "You have a typo." That is not helping, that is just pissing
people off.
And please do tell us how to do it better. Even if it is the sickest
thing in the world doesn't mean it can't also the best solution.
Critizising is easy, being constructive is hard.
I think it is the best solution for having the updates compile and
install automatically in a clean way. Now PROVE ME WRONG please.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874oeibpct....@frosties.localdomain
